From lgao at redhat.com Mon Aug 3 04:08:37 2015 From: lgao at redhat.com (Lin Gao) Date: Mon, 3 Aug 2015 04:08:37 -0400 (EDT) Subject: [wildfly-dev] Why do we need 'profile' information in the registered jdbc drivers? In-Reply-To: <242127379.4989762.1438587819343.JavaMail.zimbra@redhat.com> Message-ID: <777621082.4995847.1438589317204.JavaMail.zimbra@redhat.com> Hi, Does any body know that why do we need 'profile' information in the registered jdbc drivers? See: https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/services/driver/InstalledDriver.java#L42 Shouldn't the information like: driver-name, driver-module, driver-class-name, data-source-class-name, version etc, be enough for the registered jdbc drivers? Thank you very much! Best Regards. -- Lin Gao Software Engineer JBoss by Red Hat From ehugonne at redhat.com Mon Aug 3 05:05:58 2015 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Mon, 03 Aug 2015 11:05:58 +0200 Subject: [wildfly-dev] Why do we need 'profile' information in the registered jdbc drivers? In-Reply-To: <777621082.4995847.1438589317204.JavaMail.zimbra@redhat.com> References: <777621082.4995847.1438589317204.JavaMail.zimbra@redhat.com> Message-ID: <55BF2EF6.40403@redhat.com> Hi, https://issues.jboss.org/browse/WFLY-3634 seems to be the answer to your question. Emmanuel Le 03/08/2015 10:08, Lin Gao a ?crit : > Hi, > > Does any body know that why do we need 'profile' information in the registered jdbc drivers? See: https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/services/driver/InstalledDriver.java#L42 > > Shouldn't the information like: driver-name, driver-module, driver-class-name, data-source-class-name, version etc, be enough for the > registered jdbc drivers? Thank you very much! > > Best Regards. > -- > Lin Gao > Software Engineer > JBoss by Red Hat > _______________________________________________ > 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/20150803/27590a7b/attachment.bin From lgao at redhat.com Mon Aug 3 05:23:55 2015 From: lgao at redhat.com (Lin Gao) Date: Mon, 3 Aug 2015 05:23:55 -0400 (EDT) Subject: [wildfly-dev] Why do we need 'profile' information in the registered jdbc drivers? In-Reply-To: <55BF2EF6.40403@redhat.com> References: <777621082.4995847.1438589317204.JavaMail.zimbra@redhat.com> <55BF2EF6.40403@redhat.com> Message-ID: <72243670.5019520.1438593835885.JavaMail.zimbra@redhat.com> > > Hi, > https://issues.jboss.org/browse/WFLY-3634 seems to be the answer to your > question. > Emmanuel Yes it does. Thank you. :-) Best Regards -- Lin Gao Software Engineer JBoss by Red Hat > Le 03/08/2015 10:08, Lin Gao a ?crit : > > Hi, > > > > Does any body know that why do we need 'profile' information in the > > registered jdbc drivers? See: > > https://github.com/wildfly/wildfly/blob/master/connector/src/main/java/org/jboss/as/connector/services/driver/InstalledDriver.java#L42 > > > > Shouldn't the information like: driver-name, driver-module, > > driver-class-name, data-source-class-name, version etc, be enough for > > the > > registered jdbc drivers? Thank you very much! > > > > Best Regards. > > -- > > Lin Gao > > Software Engineer > > JBoss by Red Hat > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > From jason.greene at redhat.com Mon Aug 3 12:37:07 2015 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 3 Aug 2015 11:37:07 -0500 Subject: [wildfly-dev] Subsystem Inclusion Policy & Role of Feature Packs & Add-ons Message-ID: <2F07456A-0D5C-4084-B4F2-F818372ECD03@redhat.com> Hello Everyone, Recently there has been some confusion about how subsystems should be distributed, and whether or not they should be part of the WildFly repository. There are three primary use-cases for distributing a subsystem. #1 - Inclusion in an official WildFly distribution #2 - A user installable "add-on distribution" which can be dropped on top of a WildFly Distribution (see [A]) #3 - A separate, independant, customized distribution, with a differing identity. Possibly build but not required as a layer (see [A]) If you are after #1, then the subsystem source code (defined as the portion of code which integrates with the server using the subsystem facilities) MUST be included in the WildFly repo. This is because subsystems heavily impact the stability of the server and our compliance with our strict management compatibility policy, and additionally it allows for us to keep all included subsystems up to date with core infrastructure changes such as capabilities and requirements, and the upcoming elytron security integration. Under this approach, a feature-pack is unlikely to be used, as it would likely just be part of the full feature-pack. It could very well be that we would introduce a different more expansive feature-pack in the future defining a larger distribution foot-print, however, there are currently no plans to do so. If you are after #2, then you do not want a feature-pack, as feature-packs are just for building custom server distributions. If your use-case is #2 you are by definition not a custom server distribution, but rather a set of modules built the normal maven way. If you are after #3, then you likely wish to use the feature-pack mechanism to make it easy to produce your custom distribution. This facility would allow you to keep your source repository limited to just the new subsystems you introduce, and pull the rest of the server bits via a maven dep. It is important, that you change the identity of the server (see [A]), such that patches for the official WildFly server are not accidentally installed. Thanks! [A] https://developer.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From rory.odonnell at oracle.com Wed Aug 5 10:51:20 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Wed, 5 Aug 2015 15:51:20 +0100 Subject: [wildfly-dev] Early Access builds for JDK 8u60 b26 and JDK 9 b75 are available on java.net Message-ID: <55C222E8.4020601@oracle.com> Hi Jason/Tomaz, Early Access build for JDK 8u60 b26 is available on java.net, summary of changes are listed here. As we enter the later phases of development for JDK 8u60, please log any show stoppers as soon as possible. Early Access build for JDK 9 b75 is available on java.net, summary of changes are listed here . With respect to ongoing JDK 9 development, there are two new Candidate JEPs I'd like to draw your attention to. Firstly, Mark Reinhold has put forward JEP 260: Encapsulate Most Internal APIs to make most of the JDK's internal APIs inaccessible by default but leave a few critical, widely-used internal APIs accessible, until supported replacements exist for all or most of their functionality. You can find the JEP here: http://openjdk.java.net/jeps/260 - and an introductory e-mail and discussion thread on the OpenJDK jigsaw-dev mailing list, starting at http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-August/004433.html . If you would like to provide additional feedback, please join the jigsaw-dev mailing list, and contribute to the discussion there. Secondly, Mandy Chung has put forward JEP 259: Stack-Walking API to define an efficient standard API for stack walking that allows easy filtering of, and lazy access to, the information in stack traces. You can find the JEP here: http://openjdk.java.net/jeps/259 . If you would like to provide feedback on JEP 259, please join the OpenJDK core-libs-dev mailing list and contribute to the discussion there. Finally, we are looking for feedback via a survey on Java Style Guidelines Please see here for more details. http://mail.openjdk.java.net/pipermail/discuss/2015-August/003766.html Rgds, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150805/b8f3d4a7/attachment.html From smarlow at redhat.com Wed Aug 5 14:08:51 2015 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 5 Aug 2015 14:08:51 -0400 Subject: [wildfly-dev] Capabilities enabled by attributes In-Reply-To: <55B27CE9.2000708@redhat.com> References: <55B27CE9.2000708@redhat.com> Message-ID: <55C25133.3000209@redhat.com> On 07/24/2015 01:59 PM, Brian Stansberry wrote: > I would like to propose a requirement that if a particular type of > resource CAN provide a capability, then it MUST provide that capability > if it is created. There will be no such thing as a resource providing or > not providing a capability based on the value of one of its attributes. > > My question to subsystem developers is whether they have a situation in > their configuration model where this will be a problem? The EE client could have problems if subsystems are required to provide a capability that it could provide. Some times, a subsystem is included in the appclient.xml so that certain (subsystem related) classes are added to the application deployment classpath. Is the type of problem that your looking to hear about? > > For any case where there is such an attribute, the requirement would > mean that a child resource would need to be created instead, and that > child resource would provide the capability. There are tricks we can use > to preserve the existing attribute to provide management API compatibility. > > The only case I'm aware of where this is a factor is the 'jts' attribute > in the subsystem=transactions resource. > > The reason for this requirement is we want tooling to be able to inspect > the types of resources that are available for use, see what capabilities > they provide and what requirements they have, and work out what > resources need to be present in a configuration in order to have a > consistent set of capabilities. That task is significantly more complex > if the presence of a capability is determined by some arbitrary > attribute value. David Lloyd described allowing attributes to control > this as being "like creating an RDBMS where you have foreign keys that > only exist if some function evaluates in a certain way." > From brian.stansberry at redhat.com Wed Aug 5 14:36:31 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 5 Aug 2015 13:36:31 -0500 Subject: [wildfly-dev] Capabilities enabled by attributes In-Reply-To: <55C25133.3000209@redhat.com> References: <55B27CE9.2000708@redhat.com> <55C25133.3000209@redhat.com> Message-ID: <55C257AF.6070301@redhat.com> On 8/5/15 1:08 PM, Scott Marlow wrote: > > > On 07/24/2015 01:59 PM, Brian Stansberry wrote: >> I would like to propose a requirement that if a particular type of >> resource CAN provide a capability, then it MUST provide that capability >> if it is created. There will be no such thing as a resource providing or >> not providing a capability based on the value of one of its attributes. >> >> My question to subsystem developers is whether they have a situation in >> their configuration model where this will be a problem? > > The EE client could have problems if subsystems are required to provide > a capability that it could provide. Some times, a subsystem is included > in the appclient.xml so that certain (subsystem related) classes are > added to the application deployment classpath. > > Is the type of problem that your looking to hear about? > Not specifically, but it's a good point to clarify. :) The appclient issue is that the capability really CANNOT be provided in that process. It's not a setting of some attribute on a subsystem resource that toggles this; it's the fact that the process is not a server, it's an application client container, ProcessType.APPLICATION_CLIENT. It's fine to not register a capability if the process type is ProcessType.APPLICATION_CLIENT. I'm more looking for cases where, e.g. subsystem=jpa has attribute "foo" and if "foo" is set to 'true' a capability is registered, otherwise not. >> >> For any case where there is such an attribute, the requirement would >> mean that a child resource would need to be created instead, and that >> child resource would provide the capability. There are tricks we can use >> to preserve the existing attribute to provide management API >> compatibility. >> >> The only case I'm aware of where this is a factor is the 'jts' attribute >> in the subsystem=transactions resource. >> >> The reason for this requirement is we want tooling to be able to inspect >> the types of resources that are available for use, see what capabilities >> they provide and what requirements they have, and work out what >> resources need to be present in a configuration in order to have a >> consistent set of capabilities. That task is significantly more complex >> if the presence of a capability is determined by some arbitrary >> attribute value. David Lloyd described allowing attributes to control >> this as being "like creating an RDBMS where you have foreign keys that >> only exist if some function evaluates in a certain way." >> -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From anmiller at redhat.com Thu Aug 6 15:05:44 2015 From: anmiller at redhat.com (Andrig T. Miller) Date: Thu, 6 Aug 2015 15:05:44 -0400 (EDT) Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. In-Reply-To: <172349015.1843388.1437501488613.JavaMail.zimbra@redhat.com> References: <172349015.1843388.1437501488613.JavaMail.zimbra@redhat.com> Message-ID: <26848209.461.1438887938273.JavaMail.andrigtmiller@worklaptop.miller.org> My understanding was JDK9 was going to have a public API that replaces Unsafe. It has been discussed on the concurrency interest list a number of times. Is that not the case anymore? Andy ----- Original Message ----- > From: "Scott Stark" > To: wildfly-dev at lists.jboss.org > Sent: Tuesday, July 21, 2015 11:58:08 AM > Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. > > In case you didn't see the msg I sent to the core, I started up a > discussion thread "What are our middleware sun.misc.Unsafe uses?" > (https://developer.jboss.org/message/936359) to identify and track > the replacement for all of the Unsafe uses. As the start of the > discussion indicates, this came up because there was fear that Java > 9 would prevent access to the various internal packages. There may > be a Java EC working group on the problem, but it would be best for > use to work on getting public replacements in place by working with > our OpenJDK team lead by Andrew Haley. > > I have some comments I collected from other threads on the topic from > Andrew, Jason and David as well as the Java EC summary of the Unsafe > situation as background at the start of the thread. > > Please add to or correct anything that shows up on the thread as I > work through the projects to identify what we are using and why. > > The first think I checked out was the use of the Unsafe usage by > jboss-modules in the current wildfly trunk build. That turns out to > be synchronization primitives that have already been dropped in the > 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these > are similar workarounds for older Java platforms, but where they are > not, I want to make sure we are either tracking or creating an > OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api > replacement. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From sstark at redhat.com Thu Aug 6 15:41:04 2015 From: sstark at redhat.com (Scott Stark) Date: Thu, 6 Aug 2015 15:41:04 -0400 (EDT) Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. In-Reply-To: <26848209.461.1438887938273.JavaMail.andrigtmiller@worklaptop.miller.org> References: <172349015.1843388.1437501488613.JavaMail.zimbra@redhat.com> <26848209.461.1438887938273.JavaMail.andrigtmiller@worklaptop.miller.org> Message-ID: <201330222.5074550.1438890064001.JavaMail.zimbra@redhat.com> It came up at the Java EC level that there was not going to be a public replacement. Hence, there was a concern raised and the OpenJDK teams have most recently replied with a new JEP that is addressing this issue. http://openjdk.java.net/jeps/260 (JEP 260: Encapsulate Most Internal APIs) Not every usage from Unsafe has a targeted public replacement, but they are asking for feedback on whether what is being targeted is sufficient. ----- Original Message ----- From: "Andrig T. Miller" To: "Scott Stark" Cc: wildfly-dev at lists.jboss.org Sent: Thursday, August 6, 2015 12:05:44 PM Subject: Re: [wildfly-dev] sun.misc.Unsafe usage, etc. My understanding was JDK9 was going to have a public API that replaces Unsafe. It has been discussed on the concurrency interest list a number of times. Is that not the case anymore? Andy ----- Original Message ----- > From: "Scott Stark" > To: wildfly-dev at lists.jboss.org > Sent: Tuesday, July 21, 2015 11:58:08 AM > Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. > > In case you didn't see the msg I sent to the core, I started up a > discussion thread "What are our middleware sun.misc.Unsafe uses?" > (https://developer.jboss.org/message/936359) to identify and track > the replacement for all of the Unsafe uses. As the start of the > discussion indicates, this came up because there was fear that Java > 9 would prevent access to the various internal packages. There may > be a Java EC working group on the problem, but it would be best for > use to work on getting public replacements in place by working with > our OpenJDK team lead by Andrew Haley. > > I have some comments I collected from other threads on the topic from > Andrew, Jason and David as well as the Java EC summary of the Unsafe > situation as background at the start of the thread. > > Please add to or correct anything that shows up on the thread as I > work through the projects to identify what we are using and why. > > The first think I checked out was the use of the Unsafe usage by > jboss-modules in the current wildfly trunk build. That turns out to > be synchronization primitives that have already been dropped in the > 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these > are similar workarounds for older Java platforms, but where they are > not, I want to make sure we are either tracking or creating an > OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api > replacement. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From Andreas.Kalk at nordsee.com Thu Aug 6 16:02:53 2015 From: Andreas.Kalk at nordsee.com (Andreas.Kalk at nordsee.com) Date: Thu, 6 Aug 2015 22:02:53 +0200 Subject: [wildfly-dev] =?iso-8859-1?q?AUTO=3A_Andreas_Kalk_ist_au=DFer_Hau?= =?iso-8859-1?q?s_=28returning_24=2E08=2E2015=29__=5BVirus_checked=5D?= Message-ID: Ich kehre zur?ck am 24.08.2015. Ich werde ab 03.08.2015 nicht im B?ro sein. Ich kehre zur?ck am 24.08.2015. Ich werde Ihre Nachricht nach meiner R?ckkehr beantworten. In dringenden F?llen wenden Sie sich bitte an den Support (1377) Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "wildfly-dev Digest, Vol 29, Issue 1 [Virus checked]" gesendet am 06.08.2015 21:05:47. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, w?hrend diese Person abwesend ist. Jetzt NEU: Unser R?ucherlachs-Walnussbrot. Das d?rfen Sie sich nicht entgehen lassen! -- P Denken Sie bitte an die Umwelt - bevor Sie ausdrucken! NORDSEE Holding GmbH * Klu?mannstra?e 3 * 27570 Bremerhaven Registergericht Bremen * Reg.-Nr. HRB 3579 Gesch?ftsf?hrer: Hiltrud Seggewi? (Vors.) * Robert Jung * Claus Schl?ter Aufsichtsratsvorsitzender: Heiner Kamps From mnovak at redhat.com Fri Aug 7 02:26:20 2015 From: mnovak at redhat.com (Miroslav Novak) Date: Fri, 7 Aug 2015 02:26:20 -0400 (EDT) Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <13696818.9474401.1438928691365.JavaMail.zimbra@redhat.com> Message-ID: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> Hi, we have a few questions related to correct behavior of the :migrate operation for following subsystems: - JBoss Web to Undertow [1] - HornetQ to Apache ActiveMQ Artemis [2] - jacorb to iiop-openjdk [3] Part of it was already clarified on wildfly-dev list [4] but there are still unspecified topics related to work flow and expected results of migration operation. We summarized them into following questions: 1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode? 2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning? -- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding? 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem? -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem? 4. What should happen if some other subsystem is expecting definition of element in new migrated configuration but it's not there after migration? -- For example ejb subsystem has by default "activemq-ra" as default resource adapter for MDBs and migrated Artemis subsystem will not contain it. 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this? 6. Should the extensions for old subsystems be left in configuration after migration? 7. Should the :migrate operation return reload-required header? Thank you, Mirek [1] https://issues.jboss.org/browse/EAP7-326 [2] https://issues.jboss.org/browse/EAP7-327 [3] https://issues.jboss.org/browse/EAP7-328 [4] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003841.html From hrupp at redhat.com Fri Aug 7 04:37:03 2015 From: hrupp at redhat.com (Heiko W.Rupp) Date: Fri, 07 Aug 2015 10:37:03 +0200 Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. In-Reply-To: <201330222.5074550.1438890064001.JavaMail.zimbra@redhat.com> References: <172349015.1843388.1437501488613.JavaMail.zimbra@redhat.com> <26848209.461.1438887938273.JavaMail.andrigtmiller@worklaptop.miller.org> <201330222.5074550.1438890064001.JavaMail.zimbra@redhat.com> Message-ID: On 6 Aug 2015, at 21:41, Scott Stark wrote: > It came up at the Java EC level that there was not going to be a > public replacement. Hence, there was a concern raised and the OpenJDK > teams have most recently replied with a new JEP that is addressing > this issue. > http://openjdk.java.net/jeps/260 (JEP 260: Encapsulate Most Internal > APIs) Mark Reinhold wrote this email 2 days ago, that (im my understanding) says that Unsafe will stay: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-August/004433.html This then refers to JEP 260, which says that Unsafe should stay as is. From brian.stansberry at redhat.com Mon Aug 10 11:08:01 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 10 Aug 2015 10:08:01 -0500 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> Message-ID: <55C8BE51.4030203@redhat.com> Thanks for raising these questions here. On 8/7/15 1:26 AM, Miroslav Novak wrote: > Hi, > > we have a few questions related to correct behavior of the :migrate operation for following subsystems: > - JBoss Web to Undertow [1] > - HornetQ to Apache ActiveMQ Artemis [2] > - jacorb to iiop-openjdk [3] > > Part of it was already clarified on wildfly-dev list [4] but there are still unspecified topics related to work flow and expected results of migration operation. We summarized them into following questions: > > 1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode? > I'll let Jeff Mesnil, Tomasz Adamski and Stuart Douglas reply to this part. Ideally this would be covered somewhere in https://docs.jboss.org/author/display/WFLY10/Documentation. The intent is all three of these have common semantics. The biggest thing is these ops all require that the target process is running in --admin-only mode. > 2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning? > -- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding? > The migrate operation is used to migrate a valid configuration. What you describe is an invalid configuration, as the needed socket-binding is not present. The migration operation should not remove external configuration (e.g. remove a socket-binding), as the ability to determine what other uses there may be in the overall config for that config is beyond the scope of the migration op handler. > 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem? > -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem? > I'll let Stuart respond to this. Looking at the WebMigrateOperation (the handler for the web subsystem migrate op) it looks to be adding a security realm. > 4. What should happen if some other subsystem is expecting definition of element in new migrated configuration but it's not there after migration? > -- For example ejb subsystem has by default "activemq-ra" as default resource adapter for MDBs and migrated Artemis subsystem will not contain it. > Just to clarify, the default is hornetq-ra. Jeff Mesnil should reply to this. I believe this may be a situation where we change the default value of a management attribute and then use a transformer to ensure slaves running previous versions still see hornetq-ra if the attribute value is not explicitly set. > 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this? > I think the op should fail (not just warn) if the subsystem cannot be properly migrated. That said, we need to be careful about having the scope of the handlers grow too large, forcing handlers for one subsystem to be tightly coupled to the implementation details of other subsystems or the kernel. Your questions 2-4 relate to this kind of scope question. If the coupling between different parts of the system starts to get too deep, IMO it starts to move beyond the intended scope of these operations and into the realm of higher level tools like Red Hat's Windup tool. It's a judgement call but my feeling is what the handlers are currently doing (e.g. the stuff I mention in my answer to #2) is reasonable. > 6. Should the extensions for old subsystems be left in configuration after migration? > In a domain, yes. The migration of a subsystem in one profile does not mean the extension is unavailable for use in another profile. I don't have a strong opinion about this in standalone. I do suspect there may be a technical barrier to removing the extension though. If so I doubt we'll do it in WildFly 10. > 7. Should the :migrate operation return reload-required header? > The migrate operations function by executing operations to add and remove resources. If those operations themselves put the process in reload-required, then the header will be returned. If not, it won't. The migrate operations all require that the process be running in --admin-only mode. So I would not expect the outcome to be a need to put the process in reload-required. Most likely that outcome would be a bug. We use reload-required when changes to the persistent configuration cannot be reflected in existing running services, but in --admin-only there are no running services associated with these subsystems. > Thank you, > Mirek > > [1] https://issues.jboss.org/browse/EAP7-326 > [2] https://issues.jboss.org/browse/EAP7-327 > [3] https://issues.jboss.org/browse/EAP7-328 > [4] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003841.html > _______________________________________________ > 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 lthon at redhat.com Mon Aug 10 11:59:05 2015 From: lthon at redhat.com (Ladislav Thon) Date: Mon, 10 Aug 2015 17:59:05 +0200 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55C8BE51.4030203@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> Message-ID: <55C8CA49.2020504@redhat.com> Brian, thanks for answering. I'll clarify some qustions below (and I hope that others from our team will join too). >> 1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode? >> > > I'll let Jeff Mesnil, Tomasz Adamski and Stuart Douglas reply to this > part. Ideally this would be covered somewhere in > https://docs.jboss.org/author/display/WFLY10/Documentation. The intent > is all three of these have common semantics. > > The biggest thing is these ops all require that the target process is > running in --admin-only mode. This is mostly about clarifying what should I do before starting the new server in --admin-only. In standalone -- am I supposed to copy snippets from old standalone.xml to new standalone.xml? In domain -- uh oh, sorry, I don't really know, maybe this is somehow connected to the ability of newer domain controller to manage older servers? >> 2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning? >> -- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding? >> > > The migrate operation is used to migrate a valid configuration. What you > describe is an invalid configuration, as the needed socket-binding is > not present. So if the migration approach is to "copy all required snippets from old configuration to the new one", I have to copy all dependencies (e.g. socket bindings) too. Makes sense, though maybe we had a different situation in mind here that I can't recollect now... :-( > The migration operation should not remove external configuration (e.g. > remove a socket-binding), as the ability to determine what other uses > there may be in the overall config for that config is beyond the scope > of the migration op handler. Sure. >> 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem? >> -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem? >> > > I'll let Stuart respond to this. Looking at the WebMigrateOperation (the > handler for the web subsystem migrate op) it looks to be adding a > security realm. This is probably the right thing to do, but we wanted to be sure. We've seen some possible problems with this (e.g. name collisions), so we thought that it's better to ask :-) >> 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this? >> > > I think the op should fail (not just warn) if the subsystem cannot be > properly migrated. I can agree both with this and with the other approach of "it's probably easier for the user to fixup the new subsystem then it is to repeatedly alter the old subsystem until you get something that will convert" [1]. [1] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003855.html The idea here is that if the :migrate operation can see a possible problem, then the problem must be reported during :migrate and not only when the migrated server is started for the first time. Of course I agree with > That said, we need to be careful about having the scope of the handlers > grow too large, forcing handlers for one subsystem to be tightly coupled > to the implementation details of other subsystems or the kernel. Your > questions 2-4 relate to this kind of scope question. If the coupling > between different parts of the system starts to get too deep, IMO it > starts to move beyond the intended scope of these operations and into > the realm of higher level tools like Red Hat's Windup tool. It's a > judgement call but my feeling is what the handlers are currently doing > (e.g. the stuff I mention in my answer to #2) is reasonable. and my opinion here is that the :migrate operation should detect any possible problems that stem from the configuration of the old subsystem (e.g. an attribute in the old subsystem allowed values A|B|C, but the new subsystem only allows A|B). Problems caused elsewhere (socket bindings, other subsystems, ...) can be deferred to server startup. The key here is to agree on this :-) >> 6. Should the extensions for old subsystems be left in configuration after migration? >> > > In a domain, yes. The migration of a subsystem in one profile does not > mean the extension is unavailable for use in another profile. > > I don't have a strong opinion about this in standalone. > > I do suspect there may be a technical barrier to removing the extension > though. If so I doubt we'll do it in WildFly 10. I think we're fine with leaving them there, this was just to clarify. >> 7. Should the :migrate operation return reload-required header? >> > > The migrate operations function by executing operations to add and > remove resources. If those operations themselves put the process in > reload-required, then the header will be returned. If not, it won't. > > The migrate operations all require that the process be running in > --admin-only mode. So I would not expect the outcome to be a need to put > the process in reload-required. Most likely that outcome would be a bug. > We use reload-required when changes to the persistent configuration > cannot be reflected in existing running services, but in --admin-only > there are no running services associated with these subsystems. Makes sense, thanks. LT From fjuma at redhat.com Mon Aug 10 12:04:00 2015 From: fjuma at redhat.com (Farah Juma) Date: Mon, 10 Aug 2015 12:04:00 -0400 (EDT) Subject: [wildfly-dev] WildFly 10.0.0.Beta1 is now on OpenShift In-Reply-To: <1954060848.4613204.1439222036639.JavaMail.zimbra@redhat.com> Message-ID: <1337173377.4615983.1439222640724.JavaMail.zimbra@redhat.com> See https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-10 to get started. From tomaz.cerar at gmail.com Mon Aug 10 12:24:11 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 10 Aug 2015 18:24:11 +0200 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55C8BE51.4030203@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> Message-ID: On Mon, Aug 10, 2015 at 5:08 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > > In a domain, yes. The migration of a subsystem in one profile does not > mean the extension is unavailable for use in another profile. > > I don't have a strong opinion about this in standalone. > Standalone shouldn't boot in non admin mode with legacy extensions, as they are only allowed to run in host controller and in admin mode. At least that is the contract of AbstractLegacyExtension that all deprecated / legacy extensions extend(ed) Recently(as part of adding :migrate op) some of legacy extensions ware changed back to not use AbstractLegacyExtension, but that was probably just because we haven't defined in what the lifecycle they should run given that they have migrate operation defined. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150810/b19c4186/attachment.html From brian.stansberry at redhat.com Mon Aug 10 12:33:13 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 10 Aug 2015 11:33:13 -0500 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55C8CA49.2020504@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C8CA49.2020504@redhat.com> Message-ID: <55C8D249.5050603@redhat.com> On 8/10/15 10:59 AM, Ladislav Thon wrote: > Brian, thanks for answering. I'll clarify some qustions below (and I > hope that others from our team will join too). > >>> 1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode? >>> >> >> I'll let Jeff Mesnil, Tomasz Adamski and Stuart Douglas reply to this >> part. Ideally this would be covered somewhere in >> https://docs.jboss.org/author/display/WFLY10/Documentation. The intent >> is all three of these have common semantics. >> >> The biggest thing is these ops all require that the target process is >> running in --admin-only mode. > > This is mostly about clarifying what should I do before starting the new > server in --admin-only. > > In standalone -- am I supposed to copy snippets from old standalone.xml > to new standalone.xml? > > In domain -- uh oh, sorry, I don't really know, maybe this is somehow > connected to the ability of newer domain controller to manage older servers? > The intent here was not to let people start with a new standard config shipped by us and then use these ops to import stuff from a previous config. The expectation is they are starting with their existing config and changing it. It's possible they'll want to start with some sort of a hybrid, i.e. take our new standard config, then bring their own stuff in, and then let us migrate parts. If so the user is responsible for creating that initial hybrid. If some other tooling helps them with that, all the better, but that's out of scope for these ops. >>> 2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning? >>> -- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding? >>> >> >> The migrate operation is used to migrate a valid configuration. What you >> describe is an invalid configuration, as the needed socket-binding is >> not present. > > So if the migration approach is to "copy all required snippets from old > configuration to the new one", I have to copy all dependencies (e.g. > socket bindings) too. Makes sense, though maybe we had a different > situation in mind here that I can't recollect now... :-( > >> The migration operation should not remove external configuration (e.g. >> remove a socket-binding), as the ability to determine what other uses >> there may be in the overall config for that config is beyond the scope >> of the migration op handler. > > Sure. > >>> 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem? >>> -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem? >>> >> >> I'll let Stuart respond to this. Looking at the WebMigrateOperation (the >> handler for the web subsystem migrate op) it looks to be adding a >> security realm. > > This is probably the right thing to do, but we wanted to be sure. We've > seen some possible problems with this (e.g. name collisions), so we > thought that it's better to ask :-) > It's a good question. They all are. :) What WebMigrateOperation does is create a synthetic realm name by starting with a base name and adding a digit, looping and incrementing the digit until it finds a name that doesn't collide. >>> 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this? >>> >> >> I think the op should fail (not just warn) if the subsystem cannot be >> properly migrated. > > I can agree both with this and with the other approach of "it's probably > easier for the user to fixup the new subsystem then it is to repeatedly > alter the old subsystem until you get something that will convert" [1]. > > [1] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003855.html > > The idea here is that if the :migrate operation can see a possible > problem, then the problem must be reported during :migrate and not only > when the migrated server is started for the first time. Of course I > agree with Good point. I'll let Jason and the guys who actually wrote these respond further. The idea of warning is problematic. Management ops return a result or a failure, not a result + a warning. We can of course warn in the server log, but I think it's dangerous to reply with a success result and then count on the possibly-remote user to notice a server log message. If we don't warn but fail it certainly makes sense for these handlers to defer failing as long as possible and gather up all problems into one failure message. > >> That said, we need to be careful about having the scope of the handlers >> grow too large, forcing handlers for one subsystem to be tightly coupled >> to the implementation details of other subsystems or the kernel. Your >> questions 2-4 relate to this kind of scope question. If the coupling >> between different parts of the system starts to get too deep, IMO it >> starts to move beyond the intended scope of these operations and into >> the realm of higher level tools like Red Hat's Windup tool. It's a >> judgement call but my feeling is what the handlers are currently doing >> (e.g. the stuff I mention in my answer to #2) is reasonable. > > and my opinion here is that the :migrate operation should detect any > possible problems that stem from the configuration of the old subsystem > (e.g. an attribute in the old subsystem allowed values A|B|C, but the > new subsystem only allows A|B). Problems caused elsewhere (socket > bindings, other subsystems, ...) can be deferred to server startup. > > The key here is to agree on this :-) > I agree with that. >>> 6. Should the extensions for old subsystems be left in configuration after migration? >>> >> >> In a domain, yes. The migration of a subsystem in one profile does not >> mean the extension is unavailable for use in another profile. >> >> I don't have a strong opinion about this in standalone. >> >> I do suspect there may be a technical barrier to removing the extension >> though. If so I doubt we'll do it in WildFly 10. > > I think we're fine with leaving them there, this was just to clarify. > >>> 7. Should the :migrate operation return reload-required header? >>> >> >> The migrate operations function by executing operations to add and >> remove resources. If those operations themselves put the process in >> reload-required, then the header will be returned. If not, it won't. >> >> The migrate operations all require that the process be running in >> --admin-only mode. So I would not expect the outcome to be a need to put >> the process in reload-required. Most likely that outcome would be a bug. >> We use reload-required when changes to the persistent configuration >> cannot be reflected in existing running services, but in --admin-only >> there are no running services associated with these subsystems. > > Makes sense, thanks. > > LT > _______________________________________________ > 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 ehugonne at redhat.com Mon Aug 10 12:53:33 2015 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Mon, 10 Aug 2015 18:53:33 +0200 Subject: [wildfly-dev] Validating operation parameters Message-ID: <55C8D70D.5090303@redhat.com> Hi, I'm currently working on adding more metadata on resource attributes and operation parameters or replies [1]. As an example I added the fact that an attribute of type STRING is in fact a filesystem path or an URL [2]. To show how this kind of metadata could be helpful I have updated the CLI so that it uses the filesystem path completer and to try to validate the operation parameters : for example checking that an URL has a correct format before executing an operation. This led me to provide more validation : checking that an integer is in the valid range, etc. Brian rightfully pointed out that in some case we are defining than an operation parameter is defined a certain type while the handler supports multiple types : for example the DeploymentAddhandler.CONTENT_ALL should get a LIST of only one object but supports getting the object directly. So I'm wondering about adding support for range or type validation for 'complex' types as it may break existing valid (as in accepted even if wrong) operations. What do you think ? Do you see other edge cases like this one ? Emmanuel 1: https://issues.jboss.org/browse/WFCORE-74 2: https://github.com/ehsavoie/wildfly-core/tree/WFCORE-74 -------------- 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/20150810/fbb5a49c/attachment.bin From brian.stansberry at redhat.com Mon Aug 10 13:14:37 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 10 Aug 2015 12:14:37 -0500 Subject: [wildfly-dev] Validating operation parameters In-Reply-To: <55C8D70D.5090303@redhat.com> References: <55C8D70D.5090303@redhat.com> Message-ID: <55C8DBFD.8070307@redhat.com> Please search for uses of the ParameterCorrector interface. Its function is to allow server side handlers to adjust things. This should not be part of WFCORE-74. It's a separate, more far reaching task. In general I don't think this kind of client side validation is worth the loss of flexibility. We have tab completion to help suggest correct values. Min/max validation is least likely to introduce problems. Just dreaming, I can imagine an enum value being dropped from the list of "legal" values, but the OSH still accepts/translates the old value to provide compatibility for old scripts. That's somewhat broken and is a bit of a corner case, but it's another example of how the server can be "forgiving." What sort of path validation did you have in mind? The remote client cannot know what filesystems are in use in all possible locations affected by an op, so I don't see how it can validate. On 8/10/15 11:53 AM, Emmanuel Hugonnet wrote: > Hi, > I'm currently working on adding more metadata on resource attributes and operation parameters or replies [1]. > As an example I added the fact that an attribute of type STRING is in fact a filesystem path or an URL [2]. > To show how this kind of metadata could be helpful I have updated the CLI so that it uses the filesystem path completer and to try to > validate the operation parameters : > for example checking that an URL has a correct format before executing an operation. > This led me to provide more validation : checking that an integer is in the valid range, etc. > Brian rightfully pointed out that in some case we are defining than an operation parameter is defined a certain type while the handler > supports multiple types : > for example the DeploymentAddhandler.CONTENT_ALL should get a LIST of only one object but supports getting the object directly. > So I'm wondering about adding support for range or type validation for 'complex' types as it may break existing valid (as in accepted even > if wrong) operations. > What do you think ? Do you see other edge cases like this one ? > Emmanuel > > 1: https://issues.jboss.org/browse/WFCORE-74 > 2: https://github.com/ehsavoie/wildfly-core/tree/WFCORE-74 > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From smarlow at redhat.com Mon Aug 10 15:30:38 2015 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 10 Aug 2015 15:30:38 -0400 Subject: [wildfly-dev] Using a custom module to preview "next-gen" Hibernate versions on WildFly 9 In-Reply-To: References: Message-ID: <55C8FBDE.5090902@redhat.com> Sanne, I created WFLY-5075 for the bug you hit with your second experiment. Thanks for reporting it. Scott On 05/21/2015 07:30 AM, Sanne Grinovero wrote: > # Second experiment - use the "application provided" > > In this case I hope to hint the JPA deployer to not add the default > implementor but look for a JPA implementation within my deployment, > but still package my custom Hibernate build as a module. > > - use the same custom module containing Hibernate ORM 5 (a preview snapshot) > - Add a "Dependency:" section to the manifest to import (and export) > my custom module > - set the "jboss.as.jpa.providerModule" property to value "application" > > This gets me: > > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: > WFLYJPA0027: Persistence provider module load error application (class > org.hibernate.jpa.HibernatePersistenceProvider) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:985) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.addPuService(PersistenceUnitServiceHandler.java:267) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.handleWarDeployment(PersistenceUnitServiceHandler.java:200) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:131) > at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) > [wildfly-server-1.0.0.CR1.jar:1.0.0.CR1] > ... 5 more > Caused by: org.jboss.modules.ModuleNotFoundException: application:main > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) > [jboss-modules.jar:1.4.3.Final] > at org.jboss.as.jpa.persistenceprovider.PersistenceProviderLoader.loadProviderModuleByName(PersistenceProviderLoader.java:65) > at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:978) > ... 10 more > > Remarks: > - it's attempting to load the "application:main" module?! From ehugonne at redhat.com Mon Aug 10 16:02:25 2015 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Mon, 10 Aug 2015 22:02:25 +0200 Subject: [wildfly-dev] Validating operation parameters In-Reply-To: <55C8DBFD.8070307@redhat.com> References: <55C8D70D.5090303@redhat.com> <55C8DBFD.8070307@redhat.com> Message-ID: <55C90351.2090501@redhat.com> Comments inline Le 10/08/2015 19:14, Brian Stansberry a ?crit : > Please search for uses of the ParameterCorrector interface. Its function > is to allow server side handlers to adjust things. > > This should not be part of WFCORE-74. It's a separate, more far reaching > task. Agreed, the CLI client side validation was more a POC on how to use the 'new' arbitrary descriptor. > > In general I don't think this kind of client side validation is worth > the loss of flexibility. We have tab completion to help suggest correct > values. > > Min/max validation is least likely to introduce problems. Yes,that's why I didn't go further :D > > Just dreaming, I can imagine an enum value being dropped from the list > of "legal" values, but the OSH still accepts/translates the old value to > provide compatibility for old scripts. That's somewhat broken and is a > bit of a corner case, but it's another example of how the server can be > "forgiving." > > What sort of path validation did you have in mind? The remote client > cannot know what filesystems are in use in all possible locations > affected by an op, so I don't see how it can validate. Currently it doesn't aim to validate a path but the CLI now use the FilenameTabCompleter so you can use tab to complete the attribute (using a local to the cli path). But for URL we could validate JDBC urls for example, or check that a web URL is reachable or at least is correct, or use SSL... This also could be useful for JNDI names in completion as well as in validation : at least some basic format validation. Emmanuel > > On 8/10/15 11:53 AM, Emmanuel Hugonnet wrote: >> Hi, >> I'm currently working on adding more metadata on resource attributes and operation parameters or replies [1]. >> As an example I added the fact that an attribute of type STRING is in fact a filesystem path or an URL [2]. >> To show how this kind of metadata could be helpful I have updated the CLI so that it uses the filesystem path completer and to try to >> validate the operation parameters : >> for example checking that an URL has a correct format before executing an operation. >> This led me to provide more validation : checking that an integer is in the valid range, etc. >> Brian rightfully pointed out that in some case we are defining than an operation parameter is defined a certain type while the handler >> supports multiple types : >> for example the DeploymentAddhandler.CONTENT_ALL should get a LIST of only one object but supports getting the object directly. >> So I'm wondering about adding support for range or type validation for 'complex' types as it may break existing valid (as in accepted even >> if wrong) operations. >> What do you think ? Do you see other edge cases like this one ? >> Emmanuel >> >> 1: https://issues.jboss.org/browse/WFCORE-74 >> 2: https://github.com/ehsavoie/wildfly-core/tree/WFCORE-74 >> >> >> >> _______________________________________________ >> 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/20150810/3e6fd586/attachment-0001.bin From jason.greene at redhat.com Mon Aug 10 16:23:39 2015 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 10 Aug 2015 15:23:39 -0500 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55C8D249.5050603@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C8CA49.2020504@redhat.com> <55C8D249.5050603@redhat.com> Message-ID: <76D101D8-07EC-4ECE-94BD-3B8C53616E96@redhat.com> > On Aug 10, 2015, at 11:33 AM, Brian Stansberry wrote: > > On 8/10/15 10:59 AM, Ladislav Thon wrote: >> Brian, thanks for answering. I'll clarify some qustions below (and I >> hope that others from our team will join too). >> >>>> 1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode? >>>> >>> >>> I'll let Jeff Mesnil, Tomasz Adamski and Stuart Douglas reply to this >>> part. Ideally this would be covered somewhere in >>> https://docs.jboss.org/author/display/WFLY10/Documentation. The intent >>> is all three of these have common semantics. >>> >>> The biggest thing is these ops all require that the target process is >>> running in --admin-only mode. >> >> This is mostly about clarifying what should I do before starting the new >> server in --admin-only. >> >> In standalone -- am I supposed to copy snippets from old standalone.xml >> to new standalone.xml? >> >> In domain -- uh oh, sorry, I don't really know, maybe this is somehow >> connected to the ability of newer domain controller to manage older servers? >> > > The intent here was not to let people start with a new standard config > shipped by us and then use these ops to import stuff from a previous > config. The expectation is they are starting with their existing config > and changing it. > > It's possible they'll want to start with some sort of a hybrid, i.e. > take our new standard config, then bring their own stuff in, and then > let us migrate parts. If so the user is responsible for creating that > initial hybrid. If some other tooling helps them with that, all the > better, but that's out of scope for these ops. > >>>> 2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning? >>>> -- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding? >>>> >>> >>> The migrate operation is used to migrate a valid configuration. What you >>> describe is an invalid configuration, as the needed socket-binding is >>> not present. >> >> So if the migration approach is to "copy all required snippets from old >> configuration to the new one", I have to copy all dependencies (e.g. >> socket bindings) too. Makes sense, though maybe we had a different >> situation in mind here that I can't recollect now... :-( >> >>> The migration operation should not remove external configuration (e.g. >>> remove a socket-binding), as the ability to determine what other uses >>> there may be in the overall config for that config is beyond the scope >>> of the migration op handler. >> >> Sure. >> >>>> 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem? >>>> -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem? >>>> >>> >>> I'll let Stuart respond to this. Looking at the WebMigrateOperation (the >>> handler for the web subsystem migrate op) it looks to be adding a >>> security realm. >> >> This is probably the right thing to do, but we wanted to be sure. We've >> seen some possible problems with this (e.g. name collisions), so we >> thought that it's better to ask :-) >> > > It's a good question. They all are. :) > > What WebMigrateOperation does is create a synthetic realm name by > starting with a base name and adding a digit, looping and incrementing > the digit until it finds a name that doesn't collide. > >>>> 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this? >>>> >>> >>> I think the op should fail (not just warn) if the subsystem cannot be >>> properly migrated. >> >> I can agree both with this and with the other approach of "it's probably >> easier for the user to fixup the new subsystem then it is to repeatedly >> alter the old subsystem until you get something that will convert" [1]. >> >> [1] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003855.html >> >> The idea here is that if the :migrate operation can see a possible >> problem, then the problem must be reported during :migrate and not only >> when the migrated server is started for the first time. Of course I >> agree with > > Good point. I'll let Jason and the guys who actually wrote these respond > further. I was simply voicing an opinion at the time. I think the conversation ended at that point, and I didn?t feel strongly enough about it raise it again. > > The idea of warning is problematic. Management ops return a result or a > failure, not a result + a warning. We can of course warn in the server > log, but I think it's dangerous to reply with a success result and then > count on the possibly-remote user to notice a server log message. Right my thinking was the result would be the migration status. The actual migration is the actions it takes. Granted, a major challenge is that all of this work happens in a composite. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From brian.stansberry at redhat.com Mon Aug 10 17:30:51 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 10 Aug 2015 16:30:51 -0500 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <76D101D8-07EC-4ECE-94BD-3B8C53616E96@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C8CA49.2020504@redhat.com> <55C8D249.5050603@redhat.com> <76D101D8-07EC-4ECE-94BD-3B8C53616E96@redhat.com> Message-ID: <55C9180B.90206@redhat.com> On 8/10/15 3:23 PM, Jason Greene wrote: > >> On Aug 10, 2015, at 11:33 AM, Brian Stansberry wrote: >> >> On 8/10/15 10:59 AM, Ladislav Thon wrote: >>> Brian, thanks for answering. I'll clarify some qustions below (and I >>> hope that others from our team will join too). >>> >>>>> 1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode? >>>>> >>>> >>>> I'll let Jeff Mesnil, Tomasz Adamski and Stuart Douglas reply to this >>>> part. Ideally this would be covered somewhere in >>>> https://docs.jboss.org/author/display/WFLY10/Documentation. The intent >>>> is all three of these have common semantics. >>>> >>>> The biggest thing is these ops all require that the target process is >>>> running in --admin-only mode. >>> >>> This is mostly about clarifying what should I do before starting the new >>> server in --admin-only. >>> >>> In standalone -- am I supposed to copy snippets from old standalone.xml >>> to new standalone.xml? >>> >>> In domain -- uh oh, sorry, I don't really know, maybe this is somehow >>> connected to the ability of newer domain controller to manage older servers? >>> >> >> The intent here was not to let people start with a new standard config >> shipped by us and then use these ops to import stuff from a previous >> config. The expectation is they are starting with their existing config >> and changing it. >> >> It's possible they'll want to start with some sort of a hybrid, i.e. >> take our new standard config, then bring their own stuff in, and then >> let us migrate parts. If so the user is responsible for creating that >> initial hybrid. If some other tooling helps them with that, all the >> better, but that's out of scope for these ops. >> >>>>> 2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning? >>>>> -- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding? >>>>> >>>> >>>> The migrate operation is used to migrate a valid configuration. What you >>>> describe is an invalid configuration, as the needed socket-binding is >>>> not present. >>> >>> So if the migration approach is to "copy all required snippets from old >>> configuration to the new one", I have to copy all dependencies (e.g. >>> socket bindings) too. Makes sense, though maybe we had a different >>> situation in mind here that I can't recollect now... :-( >>> >>>> The migration operation should not remove external configuration (e.g. >>>> remove a socket-binding), as the ability to determine what other uses >>>> there may be in the overall config for that config is beyond the scope >>>> of the migration op handler. >>> >>> Sure. >>> >>>>> 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem? >>>>> -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem? >>>>> >>>> >>>> I'll let Stuart respond to this. Looking at the WebMigrateOperation (the >>>> handler for the web subsystem migrate op) it looks to be adding a >>>> security realm. >>> >>> This is probably the right thing to do, but we wanted to be sure. We've >>> seen some possible problems with this (e.g. name collisions), so we >>> thought that it's better to ask :-) >>> >> >> It's a good question. They all are. :) >> >> What WebMigrateOperation does is create a synthetic realm name by >> starting with a base name and adding a digit, looping and incrementing >> the digit until it finds a name that doesn't collide. >> >>>>> 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this? >>>>> >>>> >>>> I think the op should fail (not just warn) if the subsystem cannot be >>>> properly migrated. >>> >>> I can agree both with this and with the other approach of "it's probably >>> easier for the user to fixup the new subsystem then it is to repeatedly >>> alter the old subsystem until you get something that will convert" [1]. >>> >>> [1] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003855.html >>> >>> The idea here is that if the :migrate operation can see a possible >>> problem, then the problem must be reported during :migrate and not only >>> when the migrated server is started for the first time. Of course I >>> agree with >> >> Good point. I'll let Jason and the guys who actually wrote these respond >> further. > > I was simply voicing an opinion at the time. I think the conversation ended at that point, and I didn?t feel strongly enough about it raise it again. > Ok. Well, it's in the Beta implemented as "fail if there is a problem." If anyone wants to change that, it's pretty much speak now or never. >> >> The idea of warning is problematic. Management ops return a result or a >> failure, not a result + a warning. We can of course warn in the server >> log, but I think it's dangerous to reply with a success result and then >> count on the possibly-remote user to notice a server log message. > > Right my thinking was the result would be the migration status. The actual migration is the actions it takes. Granted, a major challenge is that all of this work happens in a composite. > That could work. We also have a "describe-migration" op, for which the result is the list of ops to take to do the migration yourself. (It doesn't actually do the migration.) If we wanted some sort of "migration status" result for the "migrate" op we'd need to change the structure of the "describe-migration" result as well to additionally include that info. The two should be consistent about this. When you talk about "composite" are you referring to the not multi-step nature of how these ops actually internally do the migration? If so I don't think dealing with those other steps is practical. The only thing we could warn about would be stuff the migration handler itself identifies. If then there is some problem that occurs when executing the add/remove steps the migration handler runs, I don't think it's practical to do anything but fail. > > > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From stuart.w.douglas at gmail.com Mon Aug 10 18:23:03 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 11 Aug 2015 08:23:03 +1000 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55C8BE51.4030203@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> Message-ID: > > > > 3. What is the expected behavior when part which was configured as part > of the legacy subsystem is now configured outside of new subsystem having > just reference to it? Should the migration operation create the additional > configuration even when it is manipulating with configuration parts outside > of the subsystem? > > -- For example ssl configuration of https connector/listener. In Web > subsystem it is part of the connector configuration, in Undertow it is just > reference to security realm and it is defined as part of the security > realms, should new security realm be created with equivalent configuration > to the one in legacy Web subsystem? > > > > I'll let Stuart respond to this. Looking at the WebMigrateOperation (the > handler for the web subsystem migrate op) it looks to be adding a > security realm. > Yes, at the moment I do create new security realms, and also add the IO subsystem with a default config if it is not already present. The names for the security realm will be jbossweb-migration-security-realm(n), where n is the lowest number that does not result in a name collision. Stuart -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150811/c265b438/attachment.html From jason.greene at redhat.com Mon Aug 10 20:40:30 2015 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 10 Aug 2015 19:40:30 -0500 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> Message-ID: > On Aug 10, 2015, at 5:23 PM, Stuart Douglas wrote: > > > > 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem? > > -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem? > > > > I'll let Stuart respond to this. Looking at the WebMigrateOperation (the > handler for the web subsystem migrate op) it looks to be adding a > security realm. > > Yes, at the moment I do create new security realms, and also add the IO subsystem with a default config if it is not already present. The names for the security realm will be jbossweb-migration-security-realm(n), where n is the lowest number that does not result in a name collision. > As an example of the fail-or-warn question, unless I am reading the code wrong, it looks like things which don?t have a mapping (e.g. tomcat valves) are ignored. Should the migration op fail if one is used, or should it return a warning? -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150810/53c8b20f/attachment.html From stuart.w.douglas at gmail.com Mon Aug 10 22:05:19 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 11 Aug 2015 02:05:19 +0000 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> Message-ID: I don't think it should fail, imagine how frustrating that would be from a users perspective, as the only course of action they have is to delete the relevant resource and try again. It would be much more user friendly IMHO to just let the op complete and then they can fix up any issues, they will still end up in the same situation, just with less work on their part. Stuart On Tue, 11 Aug 2015 at 10:40 Jason Greene wrote: > > On Aug 10, 2015, at 5:23 PM, Stuart Douglas > wrote: > > >> > 3. What is the expected behavior when part which was configured as part >> of the legacy subsystem is now configured outside of new subsystem having >> just reference to it? Should the migration operation create the additional >> configuration even when it is manipulating with configuration parts outside >> of the subsystem? >> > -- For example ssl configuration of https connector/listener. In Web >> subsystem it is part of the connector configuration, in Undertow it is just >> reference to security realm and it is defined as part of the security >> realms, should new security realm be created with equivalent configuration >> to the one in legacy Web subsystem? >> > >> >> I'll let Stuart respond to this. Looking at the WebMigrateOperation (the >> handler for the web subsystem migrate op) it looks to be adding a >> security realm. >> > > Yes, at the moment I do create new security realms, and also add the IO > subsystem with a default config if it is not already present. The names for > the security realm will be jbossweb-migration-security-realm(n), where n is > the lowest number that does not result in a name collision. > > > As an example of the fail-or-warn question, unless I am reading the code > wrong, it looks like things which don?t have a mapping (e.g. tomcat valves) > are ignored. Should the migration op fail if one is used, or should it > return a warning? > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150811/2ff0b4aa/attachment-0001.html From lthon at redhat.com Tue Aug 11 02:39:58 2015 From: lthon at redhat.com (Ladislav Thon) Date: Tue, 11 Aug 2015 08:39:58 +0200 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> Message-ID: <55C998BE.7090309@redhat.com> I agree 100% with a single note: before "they can fix up any issues", they have to know that there are issues. If the :migrate operation knows that there will be issues (e.g. valves present in the old subsystem), it would be _very nice_ if it provided a warning :-) The earlier is the user aware of [possible] issues, the better. I believe that the :migrate operations _could_ return these warnings in the operation result, but since Brian thinks that this is problematic, I'll have to leave the details up to you, guys :-) LT On 11.8.2015 04:05, Stuart Douglas wrote: > I don't think it should fail, imagine how frustrating that would be from > a users perspective, as the only course of action they have is to delete > the relevant resource and try again. It would be much more user friendly > IMHO to just let the op complete and then they can fix up any issues, > they will still end up in the same situation, just with less work on > their part. > > Stuart > > > > On Tue, 11 Aug 2015 at 10:40 Jason Greene > wrote: > > >> On Aug 10, 2015, at 5:23 PM, Stuart Douglas >> > >> wrote: >> >> >> > 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem? >> > -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem? >> > >> >> I'll let Stuart respond to this. Looking at the >> WebMigrateOperation (the >> handler for the web subsystem migrate op) it looks to be adding a >> security realm. >> >> >> Yes, at the moment I do create new security realms, and also add >> the IO subsystem with a default config if it is not already >> present. The names for the security realm will >> be jbossweb-migration-security-realm(n), where n is the lowest >> number that does not result in a name collision. >> > > As an example of the fail-or-warn question, unless I am reading the > code wrong, it looks like things which don?t have a mapping (e.g. > tomcat valves) are ignored. Should the migration op fail if one is > used, or should it return a warning? > > -- > 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 lthon at redhat.com Tue Aug 11 03:59:10 2015 From: lthon at redhat.com (Ladislav Thon) Date: Tue, 11 Aug 2015 09:59:10 +0200 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55C8D249.5050603@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C8CA49.2020504@redhat.com> <55C8D249.5050603@redhat.com> Message-ID: <55C9AB4E.4010409@redhat.com> Inline. >> This is mostly about clarifying what should I do before starting the new >> server in --admin-only. >> >> In standalone -- am I supposed to copy snippets from old standalone.xml >> to new standalone.xml? >> >> In domain -- uh oh, sorry, I don't really know, maybe this is somehow >> connected to the ability of newer domain controller to manage older servers? >> > > The intent here was not to let people start with a new standard config > shipped by us and then use these ops to import stuff from a previous > config. The expectation is they are starting with their existing config > and changing it. So this is in some ways the most important part of this discussion :-) I just took standalone-ha.xml from EAP 6.4 and tried starting WildFly 10 Beta1 with it. Failed immediately because "WFLYCTL0309: Legacy extension 'org.jboss.as.threads' is not supported on servers running this version." Removed the extension, started again, failed with "Unexpected element '{urn:jboss:domain:threads:1.1}subsystem'" (of course!). Removed the "threads" subsystem, started again, failed with two error messages related to the "datasources" and "ejb3" subsystems. Is this the intended workflow? I didn't get further, because I somehow get a feeling that patching the new default configuration with relevant bits from the old one will be easier when only a handful of changes in the configuration were made, and probably on-par when the configuration changes were more involved. Of course it's just a feeling, but the first impression is important too :-) > It's possible they'll want to start with some sort of a hybrid, i.e. > take our new standard config, then bring their own stuff in, and then > let us migrate parts. If so the user is responsible for creating that > initial hybrid. If some other tooling helps them with that, all the > better, but that's out of scope for these ops. Of course, no question about that. LT From stuart.w.douglas at gmail.com Tue Aug 11 04:08:35 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 11 Aug 2015 08:08:35 +0000 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55C9AB4E.4010409@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C8CA49.2020504@redhat.com> <55C8D249.5050603@redhat.com> <55C9AB4E.4010409@redhat.com> Message-ID: On Tue, 11 Aug 2015 at 17:59 Ladislav Thon wrote: > Inline. > > >> This is mostly about clarifying what should I do before starting the new > >> server in --admin-only. > >> > >> In standalone -- am I supposed to copy snippets from old standalone.xml > >> to new standalone.xml? > >> > >> In domain -- uh oh, sorry, I don't really know, maybe this is somehow > >> connected to the ability of newer domain controller to manage older > servers? > >> > > > > The intent here was not to let people start with a new standard config > > shipped by us and then use these ops to import stuff from a previous > > config. The expectation is they are starting with their existing config > > and changing it. > > So this is in some ways the most important part of this discussion :-) > > I just took standalone-ha.xml from EAP 6.4 and tried starting WildFly 10 > Beta1 with it. Failed immediately because "WFLYCTL0309: Legacy extension > 'org.jboss.as.threads' is not supported on servers running this version." > > Removed the extension, started again, failed with "Unexpected element > '{urn:jboss:domain:threads:1.1}subsystem'" (of course!). > > Removed the "threads" subsystem, started again, failed with two error > messages related to the "datasources" and "ejb3" subsystems. > These are bugs. EJB and datasources are still very much supported, I am going to look into this. Stuart > > Is this the intended workflow? I didn't get further, because I somehow > get a feeling that patching the new default configuration with relevant > bits from the old one will be easier when only a handful of changes in > the configuration were made, and probably on-par when the configuration > changes were more involved. Of course it's just a feeling, but the first > impression is important too :-) > > > It's possible they'll want to start with some sort of a hybrid, i.e. > > take our new standard config, then bring their own stuff in, and then > > let us migrate parts. If so the user is responsible for creating that > > initial hybrid. If some other tooling helps them with that, all the > > better, but that's out of scope for these ops. > > Of course, no question about that. > > LT > _______________________________________________ > 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/20150811/b0b2275d/attachment.html From brian.stansberry at redhat.com Tue Aug 11 10:17:22 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 11 Aug 2015 09:17:22 -0500 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55C998BE.7090309@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> Message-ID: <55CA03F2.5000508@redhat.com> On 8/11/15 1:39 AM, Ladislav Thon wrote: > I agree 100% with a single note: before "they can fix up any issues", > they have to know that there are issues. If the :migrate operation knows > that there will be issues (e.g. valves present in the old subsystem), it > would be _very nice_ if it provided a warning :-) The earlier is the > user aware of [possible] issues, the better. > > I believe that the :migrate operations _could_ return these warnings in > the operation result, but since Brian thinks that this is problematic, > I'll have to leave the details up to you, guys :-) > It can be done, and IMHO must be done if the handler is ignoring aspects of the migrated configuration. It just means altering the format of the result of both the "migrate" and "describe-migration" operations. The "warnings" can only be for items identified by the migration op handler directly. If any of the various add/remove ops that that handler tells the controller to execute fail, then the overall result will be a failure. That is, no attempt to hack into the handling of those ops and convert that kind of failure into a "warn". I propose the following format for the "result" field of the migrate operation response: { "migration-warnings"=>[ "WFXXX1234: the blah is blah", "WFXXX2345: the foo is barred" ] } For "describe-migration": { "migration-warnings"=>[ "WFXXX1234: the blah is blah", "WFXXX2345: the foo is barred" ], "migration-operations=>[ { an operation }, { another operation} ] } The value of the "migration-operations" field would be the same as the overall result value currently produced by these ops. > LT > > On 11.8.2015 04:05, Stuart Douglas wrote: >> I don't think it should fail, imagine how frustrating that would be from >> a users perspective, as the only course of action they have is to delete >> the relevant resource and try again. It would be much more user friendly >> IMHO to just let the op complete and then they can fix up any issues, >> they will still end up in the same situation, just with less work on >> their part. >> >> Stuart >> >> >> >> On Tue, 11 Aug 2015 at 10:40 Jason Greene > > wrote: >> >> >>> On Aug 10, 2015, at 5:23 PM, Stuart Douglas >>> > >>> wrote: >>> >>> >>> > 3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem? >>> > -- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem? >>> > >>> >>> I'll let Stuart respond to this. Looking at the >>> WebMigrateOperation (the >>> handler for the web subsystem migrate op) it looks to be adding a >>> security realm. >>> >>> >>> Yes, at the moment I do create new security realms, and also add >>> the IO subsystem with a default config if it is not already >>> present. The names for the security realm will >>> be jbossweb-migration-security-realm(n), where n is the lowest >>> number that does not result in a name collision. >>> >> >> As an example of the fail-or-warn question, unless I am reading the >> code wrong, it looks like things which don?t have a mapping (e.g. >> tomcat valves) are ignored. Should the migration op fail if one is >> used, or should it return a warning? >> >> -- >> 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 > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Tue Aug 11 11:11:43 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 11 Aug 2015 10:11:43 -0500 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55C9AB4E.4010409@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C8CA49.2020504@redhat.com> <55C8D249.5050603@redhat.com> <55C9AB4E.4010409@redhat.com> Message-ID: <55CA10AF.4040905@redhat.com> On 8/11/15 2:59 AM, Ladislav Thon wrote: > Inline. > >>> This is mostly about clarifying what should I do before starting the new >>> server in --admin-only. >>> >>> In standalone -- am I supposed to copy snippets from old standalone.xml >>> to new standalone.xml? >>> >>> In domain -- uh oh, sorry, I don't really know, maybe this is somehow >>> connected to the ability of newer domain controller to manage older servers? >>> >> >> The intent here was not to let people start with a new standard config >> shipped by us and then use these ops to import stuff from a previous >> config. The expectation is they are starting with their existing config >> and changing it. > > So this is in some ways the most important part of this discussion :-) > > I just took standalone-ha.xml from EAP 6.4 and tried starting WildFly 10 > Beta1 with it. Failed immediately because "WFLYCTL0309: Legacy extension > 'org.jboss.as.threads' is not supported on servers running this version." > > Removed the extension, started again, failed with "Unexpected element > '{urn:jboss:domain:threads:1.1}subsystem'" (of course!). > > Removed the "threads" subsystem, started again, failed with two error > messages related to the "datasources" and "ejb3" subsystems. > > Is this the intended workflow? I didn't get further, because I somehow > get a feeling that patching the new default configuration with relevant > bits from the old one will be easier when only a handful of changes in > the configuration were made, and probably on-par when the configuration > changes were more involved. Of course it's just a feeling, but the first > impression is important too :-) > Yes, that's the intended workflow, in terms of migration tooling the WildFly will provide. I think it makes sense to look into how we can ease pain as much as possible though. Things that fail, we should see if they can be made to not fail. For example, an empty threads subsystem is meaningless, so if the tread subsystem parser is running in a server and it sees the element is empty it could just basically become a no-op and not install the subsystem instead of registering an pointless subsystem that will just fail. >> It's possible they'll want to start with some sort of a hybrid, i.e. >> take our new standard config, then bring their own stuff in, and then >> let us migrate parts. If so the user is responsible for creating that >> initial hybrid. If some other tooling helps them with that, all the >> better, but that's out of scope for these ops. > > Of course, no question about that. > > LT > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Tue Aug 11 21:12:19 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 11 Aug 2015 20:12:19 -0500 Subject: [wildfly-dev] Easing migration beyond the migration ops In-Reply-To: <55CA10AF.4040905@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C8CA49.2020504@redhat.com> <55C8D249.5050603@redhat.com> <55C9AB4E.4010409@redhat.com> <55CA10AF.4040905@redhat.com> Message-ID: <55CA9D73.1080009@redhat.com> I've changed the title of this branch of the thread to better reflect this part of the topic. Plus to make it stand out more. :) More below. On 8/11/15 10:11 AM, Brian Stansberry wrote: > On 8/11/15 2:59 AM, Ladislav Thon wrote: >> Inline. >> >>>> This is mostly about clarifying what should I do before starting the >>>> new >>>> server in --admin-only. >>>> I think it makes sense to make a requirement that the user should not have to do anything before starting in --admin-only. IOW, any logic we have that rejects something on a server should not do so in --admin-only. Instead it should log a WARN advising what the user should do to correct the config. For example, "To correct this, remove the cmp subsystem." The user can then do that if they wish. In normal running mode if the config specifies things we cannot support then failing is appropriate. (There may be odd cases where for obscure stuff we decide to warn and not fail, but generally we'd fail.) >>>> In standalone -- am I supposed to copy snippets from old standalone.xml >>>> to new standalone.xml? >>>> >>>> In domain -- uh oh, sorry, I don't really know, maybe this is somehow >>>> connected to the ability of newer domain controller to manage older >>>> servers? >>>> >>> >>> The intent here was not to let people start with a new standard config >>> shipped by us and then use these ops to import stuff from a previous >>> config. The expectation is they are starting with their existing config >>> and changing it. >> >> So this is in some ways the most important part of this discussion :-) >> >> I just took standalone-ha.xml from EAP 6.4 and tried starting WildFly 10 >> Beta1 with it. Failed immediately because "WFLYCTL0309: Legacy extension >> 'org.jboss.as.threads' is not supported on servers running this version." >> >> Removed the extension, started again, failed with "Unexpected element >> '{urn:jboss:domain:threads:1.1}subsystem'" (of course!). >> >> Removed the "threads" subsystem, started again, failed with two error >> messages related to the "datasources" and "ejb3" subsystems. >> >> Is this the intended workflow? I didn't get further, because I somehow >> get a feeling that patching the new default configuration with relevant >> bits from the old one will be easier when only a handful of changes in >> the configuration were made, and probably on-par when the configuration >> changes were more involved. Of course it's just a feeling, but the first >> impression is important too :-) >> > > Yes, that's the intended workflow, in terms of migration tooling the > WildFly will provide. > > I think it makes sense to look into how we can ease pain as much as > possible though. Things that fail, we should see if they can be made to > not fail. > > For example, an empty threads subsystem is meaningless, so if the tread > subsystem parser is running in a server and it sees the element is empty > it could just basically become a no-op and not install the subsystem > instead of registering an pointless subsystem that will just fail. > This would be a specific behavior beyond the general behavior that I talk about early in this post. It could happen regardless of --admin-only. There are other "legacy only" subsystems (cmp and jaxr) that also allow an "empty" config. But I don't think this behavior is appropriate for those. Those subsystems differ from "threads" in that even an empty config affects server (i.e. deployment processing) behavior. > >>> It's possible they'll want to start with some sort of a hybrid, i.e. >>> take our new standard config, then bring their own stuff in, and then >>> let us migrate parts. If so the user is responsible for creating that >>> initial hybrid. If some other tooling helps them with that, all the >>> better, but that's out of scope for these ops. >> >> Of course, no question about that. >> >> LT >> _______________________________________________ >> 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 lthon at redhat.com Wed Aug 12 03:14:30 2015 From: lthon at redhat.com (Ladislav Thon) Date: Wed, 12 Aug 2015 09:14:30 +0200 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55CA03F2.5000508@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> Message-ID: <55CAF256.8010904@redhat.com> Inline. >> I believe that the :migrate operations _could_ return these warnings in >> the operation result, but since Brian thinks that this is problematic, >> I'll have to leave the details up to you, guys :-) >> > > It can be done, and IMHO must be done if the handler is ignoring aspects > of the migrated configuration. 100% agreed. > It just means altering the format of the > result of both the "migrate" and "describe-migration" operations. > > The "warnings" can only be for items identified by the migration op > handler directly. If any of the various add/remove ops that that handler > tells the controller to execute fail, then the overall result will be a > failure. That is, no attempt to hack into the handling of those ops and > convert that kind of failure into a "warn". I think this is expected and I'm fine with it. > I propose the following format for the "result" field of the migrate > operation response: > > { > "migration-warnings"=>[ > "WFXXX1234: the blah is blah", > "WFXXX2345: the foo is barred" > ] > } The "result" field currently contains a name and version of newly created subsystem, which should probably be preserved: [standalone at localhost:9990 /] /subsystem=jacorb:migrate { "outcome" => "success", "result" => [("iiop-openjdk" => "1.0.0")] } > For "describe-migration": > > > > { > "migration-warnings"=>[ > "WFXXX1234: the blah is blah", > "WFXXX2345: the foo is barred" > ], > "migration-operations=>[ > { an operation }, > { another operation} > ] > } > > The value of the "migration-operations" field would be the same as the > overall result value currently produced by these ops. Sounds good. LT From lthon at redhat.com Wed Aug 12 03:18:44 2015 From: lthon at redhat.com (Ladislav Thon) Date: Wed, 12 Aug 2015 09:18:44 +0200 Subject: [wildfly-dev] Easing migration beyond the migration ops In-Reply-To: <55CA9D73.1080009@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C8CA49.2020504@redhat.com> <55C8D249.5050603@redhat.com> <55C9AB4E.4010409@redhat.com> <55CA10AF.4040905@redhat.com> <55CA9D73.1080009@redhat.com> Message-ID: <55CAF354.8060502@redhat.com> > I think it makes sense to make a requirement that the user should not > have to do anything before starting in --admin-only. This would be best. However, if there's not enough time to do everything requried, then I believe that low-risk things like "remove the threads extension and the threads subsystem" could be left to the user (provided that they are documented). LT From tomaz.cerar at gmail.com Wed Aug 12 05:54:08 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 12 Aug 2015 11:54:08 +0200 Subject: [wildfly-dev] Easing migration beyond the migration ops In-Reply-To: <55CAF354.8060502@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C8CA49.2020504@redhat.com> <55C8D249.5050603@redhat.com> <55C9AB4E.4010409@redhat.com> <55CA10AF.4040905@redhat.com> <55CA9D73.1080009@redhat.com> <55CAF354.8060502@redhat.com> Message-ID: On Wed, Aug 12, 2015 at 9:18 AM, Ladislav Thon wrote: > > However, if there's not enough time to do everything requried, then I > believe that low-risk things like "remove the threads extension and the > threads subsystem" could be left to the user (provided that they are > documented). I think we could ease the threads subsystem migration. For most cases threads subsystem configuration is empty as it was just present in our default config as We can change parser that in case that only empty config is present it wont add the subsystem at all, this should ease the migration for users migrating default configurations. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150812/e059465c/attachment.html From brian.stansberry at redhat.com Wed Aug 12 10:01:28 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 12 Aug 2015 09:01:28 -0500 Subject: [wildfly-dev] Easing migration beyond the migration ops In-Reply-To: <55CAF354.8060502@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C8CA49.2020504@redhat.com> <55C8D249.5050603@redhat.com> <55C9AB4E.4010409@redhat.com> <55CA10AF.4040905@redhat.com> <55CA9D73.1080009@redhat.com> <55CAF354.8060502@redhat.com> Message-ID: <55CB51B8.9020207@redhat.com> On 8/12/15 2:18 AM, Ladislav Thon wrote: >> I think it makes sense to make a requirement that the user should not >> have to do anything before starting in --admin-only. > > This would be best. > > However, if there's not enough time to do everything requried, then I > believe that low-risk things like "remove the threads extension and the > threads subsystem" could be left to the user (provided that they are > documented). > I expect we can do what's needed. At least for the standard configs we shipped, which are easily to load and thereby find problems. https://github.com/wildfly/wildfly-core/pull/953 is a big (and quite simple) step. > LT > _______________________________________________ > 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 lthon at redhat.com Wed Aug 12 10:46:30 2015 From: lthon at redhat.com (Ladislav Thon) Date: Wed, 12 Aug 2015 16:46:30 +0200 Subject: [wildfly-dev] Easing migration beyond the migration ops In-Reply-To: <55CB51B8.9020207@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C8CA49.2020504@redhat.com> <55C8D249.5050603@redhat.com> <55C9AB4E.4010409@redhat.com> <55CA10AF.4040905@redhat.com> <55CA9D73.1080009@redhat.com> <55CAF354.8060502@redhat.com> <55CB51B8.9020207@redhat.com> Message-ID: <55CB5C46.8030706@redhat.com> > https://github.com/wildfly/wildfly-core/pull/953 is a big (and quite > simple) step. Thank you, Brian. I filed https://issues.jboss.org/browse/WFLY-5092 to cover the rest. Also, I think that we're clear on what are we supposed to file as bugs and what are the expectations, which was the ultimate goal of this conversation (and one of the outcomes will be that we'll close WFLY-5059 as invalid :-) ). So thanks again. LT From brian.stansberry at redhat.com Wed Aug 12 13:51:05 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 12 Aug 2015 12:51:05 -0500 Subject: [wildfly-dev] Easing migration beyond the migration ops In-Reply-To: <55CB5C46.8030706@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C8CA49.2020504@redhat.com> <55C8D249.5050603@redhat.com> <55C9AB4E.4010409@redhat.com> <55CA10AF.4040905@redhat.com> <55CA9D73.1080009@redhat.com> <55CAF354.8060502@redhat.com> <55CB51B8.9020207@redhat.com> <55CB5C46.8030706@redhat.com> Message-ID: <55CB8789.1030607@redhat.com> On 8/12/15 9:46 AM, Ladislav Thon wrote: > >> https://github.com/wildfly/wildfly-core/pull/953 is a big (and quite >> simple) step. > > Thank you, Brian. I filed https://issues.jboss.org/browse/WFLY-5092 to > cover the rest. > > Also, I think that we're clear on what are we supposed to file as bugs > and what are the expectations, which was the ultimate goal of this > conversation (and one of the outcomes will be that we'll close WFLY-5059 > as invalid :-) ). So thanks again. > You're very welcome. Thanks to Miroslav and yourself for the discussion. -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Aug 12 17:01:40 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 12 Aug 2015 16:01:40 -0500 Subject: [wildfly-dev] Easing migration beyond the migration ops In-Reply-To: References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C8CA49.2020504@redhat.com> <55C8D249.5050603@redhat.com> <55C9AB4E.4010409@redhat.com> <55CA10AF.4040905@redhat.com> <55CA9D73.1080009@redhat.com> <55CAF354.8060502@redhat.com> Message-ID: <55CBB434.2020905@redhat.com> On 8/12/15 4:54 AM, Toma? Cerar wrote: > > On Wed, Aug 12, 2015 at 9:18 AM, Ladislav Thon > wrote: > > > However, if there's not enough time to do everything requried, then I > believe that low-risk things like "remove the threads extension and the > threads subsystem" could be left to the user (provided that they are > documented). > > > > I think we could ease the threads subsystem migration. > For most cases threads subsystem configuration is empty as it was just > present > in our default config as > > We can change parser that in case that only empty config is present it wont > add the subsystem at all, this should ease the migration for users > migrating default configurations. > Thinking about this more, I don't think it's worthwhile. First, doing this would make the subsystem go away, but the extension will still be registered, and the user will still need to remove it. This trick only does half the job. Until the user does the other half the API to re-add the subsystem is still there to confuse users (although we'd make sure any attempt to use it out of --admin-only fails) and there would still be WARN logging during boot. Second, we wouldn't add the subsystem, but until some change to the config file happens causing a write, the subsystem will still be in the xml. That's confusing if the user notices it and violates the fundamental principle that the config file accurately represents the current in-memory config. Finally, as I mentioned elsewhere in this thread, the cmp and jaxr subsystems also ship with an empty config, but they aren't good candidates for this treatment because with those the empty subsystem really means something. So there'd be different behavior between threads and those, for non-obvious reasons. > > > _______________________________________________ > 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 Aug 13 01:27:17 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 13 Aug 2015 05:27:17 +0000 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55CA03F2.5000508@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> Message-ID: > > > I propose the following format for the "result" field of the migrate > operation response: > > { > "migration-warnings"=>[ > "WFXXX1234: the blah is blah", > "WFXXX2345: the foo is barred" > ] > } > > The current implementation use a composite operation, so the results look like: /subsystem=web:migrate { "outcome" => "success", "result" => { "step-1" => {"outcome" => "success"}, "step-2" => {"outcome" => "success"}, "step-3" => {"outcome" => "success"}, .... } } Because this is using a composite op, I am not sure how the migration-warnings should be displayed? Possibly as the results of the first step? Stuart > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150813/c179beff/attachment.html From stuart.w.douglas at gmail.com Thu Aug 13 01:50:17 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 13 Aug 2015 05:50:17 +0000 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> Message-ID: I have added this to the Undertow op here: https://github.com/wildfly/wildfly/pull/7926/files The approach I took was to add the warnings to the describe-migration op, and when running the migrate op make the describe-migration operation the first step in the composite, so the output looks like this: http://pastebin.com/B01KNAHX I am not sure how much I like it, but it also has the advantage than it displays what has been done when you are running the migrate op. I don't know much about the internals of composite operations, so I am not sure how hard it would be to somehow add this information directly. Stuart On Thu, 13 Aug 2015 at 15:27 Stuart Douglas wrote: > >> I propose the following format for the "result" field of the migrate >> operation response: >> >> { >> "migration-warnings"=>[ >> "WFXXX1234: the blah is blah", >> "WFXXX2345: the foo is barred" >> ] >> } >> >> > The current implementation use a composite operation, so the results look > like: > > /subsystem=web:migrate > { > "outcome" => "success", > "result" => { > "step-1" => {"outcome" => "success"}, > "step-2" => {"outcome" => "success"}, > "step-3" => {"outcome" => "success"}, > .... > } > } > > Because this is using a composite op, I am not sure how the > migration-warnings should be displayed? Possibly as the results of the > first step? > > Stuart > > >> >> -- >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150813/ea1499f4/attachment-0001.html From lthon at redhat.com Thu Aug 13 02:27:11 2015 From: lthon at redhat.com (Ladislav Thon) Date: Thu, 13 Aug 2015 08:27:11 +0200 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> Message-ID: <55CC38BF.8050106@redhat.com> > The approach I took was to add the warnings to the describe-migration > op, and when running the migrate op make the describe-migration > operation the first step in the composite, so the output looks like > this: http://pastebin.com/B01KNAHX The fact that it's a composite operation makes the output a bit cryptic (step-X?), but otherwise I think it's actually good. I guess that only handling the warnings in :describe-migration makes the implementation easier (not sure?) and printing :describe-migration as a part of :migrate makes sense too, precisely because it shows the steps that are performed. So my only objection would be those cryptic "step-X" names, but I guess that we can live with that (if all :migrate operations took the same approach; inconsistency wouldn't really help here). LT From stuart.w.douglas at gmail.com Thu Aug 13 04:11:30 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 13 Aug 2015 08:11:30 +0000 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55CC38BF.8050106@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> <55CC38BF.8050106@redhat.com> Message-ID: On Thu, 13 Aug 2015 at 16:27 Ladislav Thon wrote: > > > The approach I took was to add the warnings to the describe-migration > > op, and when running the migrate op make the describe-migration > > operation the first step in the composite, so the output looks like > > this: http://pastebin.com/B01KNAHX > > The fact that it's a composite operation makes the output a bit cryptic > (step-X?), but otherwise I think it's actually good. > > I guess that only handling the warnings in :describe-migration makes the > implementation easier (not sure?) and printing :describe-migration as a > part of :migrate makes sense too, precisely because it shows the steps > that are performed. > > So my only objection would be those cryptic "step-X" names, but I guess > that we can live with that (if all :migrate operations took the same > approach; inconsistency wouldn't really help here). > That is because this is implemented as a composite operation, AFAIK there is lots of special handing for composite ops, so I don't think we want to be implementing our own one with different output just for this case. I could be wrong though, this is not really my area, Brian will know more. Stuart > > LT > _______________________________________________ > 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/20150813/f18894c0/attachment.html From brian.stansberry at redhat.com Thu Aug 13 11:03:34 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 13 Aug 2015 10:03:34 -0500 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> <55CC38BF.8050106@redhat.com> Message-ID: <55CCB1C6.9030106@redhat.com> On 8/13/15 3:11 AM, Stuart Douglas wrote: > > > On Thu, 13 Aug 2015 at 16:27 Ladislav Thon > wrote: > > > > The approach I took was to add the warnings to the describe-migration > > op, and when running the migrate op make the describe-migration > > operation the first step in the composite, so the output looks like > > this: http://pastebin.com/B01KNAHX > > The fact that it's a composite operation makes the output a bit cryptic > (step-X?), but otherwise I think it's actually good. > > I guess that only handling the warnings in :describe-migration makes the > implementation easier (not sure?) and printing :describe-migration as a > part of :migrate makes sense too, precisely because it shows the steps > that are performed. > > So my only objection would be those cryptic "step-X" names, but I guess > that we can live with that (if all :migrate operations took the same > approach; inconsistency wouldn't really help here). > > > That is because this is implemented as a composite operation, AFAIK > there is lots of special handing for composite ops, so I don't think we > want to be implementing our own one with different output just for this > case. > > I could be wrong though, this is not really my area, Brian will know more. > In the success case, I don't see the point of outputting "step-2" => {"outcome" => "success"}, "step-3" => {"outcome" => "success"}, etc. In the failure case though, having an intelligible failure-description is important. And the composite op handler may be getting in your way there Instead of writing more text, I'll write some code to illustrate some thoughts and post back later. > Stuart > > > LT > _______________________________________________ > 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 Thu Aug 13 13:42:14 2015 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 13 Aug 2015 12:42:14 -0500 Subject: [wildfly-dev] Upcoming WF10 Dates (Reminder) Message-ID: <627F9528-0957-49B6-8DDB-E4D6A4138AEF@redhat.com> Hello Everyone, First off, I just wanted to say thank you everyone for hitting the major deliverables for the WF10 Beta release that went out over the weekend! The remaining schedule for WF10 is as follows: WildFly 10 CR1 - September 9th WildFly 10 CR2 (if needed) - September 16th WildFly 10 Final - October 8th (contigent on certification) So that means we have 26 days (17 workdays left) to: - Stabilize features brought in during Alpha/Beta cycle - Finish/polish compatibility (transformers, management ops, etc) - Upgrade all components to Final (preferable) or CR (exceptional) - Fix broken and/or intermittent tests relating to the above - Address any other loose ends We should avoid (if possible) introducing new major features to allow for enough time to do the above. Let me know ASAP if thats a problem. Thanks! -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From hbraun at redhat.com Thu Aug 13 14:33:19 2015 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 13 Aug 2015 20:33:19 +0200 Subject: [wildfly-dev] Upcoming WF10 Dates (Reminder) In-Reply-To: <627F9528-0957-49B6-8DDB-E4D6A4138AEF@redhat.com> References: <627F9528-0957-49B6-8DDB-E4D6A4138AEF@redhat.com> Message-ID: <0762920A-7F2E-4679-BAA7-8634407CBFE4@redhat.com> If I understand you correctly you want Final components for CR1? /Heiko > On 13 Aug 2015, at 19:42, Jason Greene wrote: > > Hello Everyone, > > First off, I just wanted to say thank you everyone for hitting the major deliverables for the WF10 Beta release that went out over the weekend! > > The remaining schedule for WF10 is as follows: > > WildFly 10 CR1 - September 9th > WildFly 10 CR2 (if needed) - September 16th > WildFly 10 Final - October 8th (contigent on certification) > > So that means we have 26 days (17 workdays left) to: > > - Stabilize features brought in during Alpha/Beta cycle > - Finish/polish compatibility (transformers, management ops, etc) > - Upgrade all components to Final (preferable) or CR (exceptional) > - Fix broken and/or intermittent tests relating to the above > - Address any other loose ends > > We should avoid (if possible) introducing new major features to allow for enough time to do the above. Let me know ASAP if thats a problem. > > Thanks! > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Thu Aug 13 15:48:38 2015 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 13 Aug 2015 14:48:38 -0500 Subject: [wildfly-dev] Upcoming WF10 Dates (Reminder) In-Reply-To: <0762920A-7F2E-4679-BAA7-8634407CBFE4@redhat.com> References: <627F9528-0957-49B6-8DDB-E4D6A4138AEF@redhat.com> <0762920A-7F2E-4679-BAA7-8634407CBFE4@redhat.com> Message-ID: <7DC21E77-056E-4AF7-B43E-99FEB381AD4C@redhat.com> That?s correct, that?s my preference. The rationale is to limit the amount of component updates we have to bring in during the CR phase. Ideally if we are pulling in an update its to resolve an issue. > On Aug 13, 2015, at 1:33 PM, Heiko Braun wrote: > > If I understand you correctly you want Final components for CR1? > > /Heiko > >> On 13 Aug 2015, at 19:42, Jason Greene wrote: >> >> Hello Everyone, >> >> First off, I just wanted to say thank you everyone for hitting the major deliverables for the WF10 Beta release that went out over the weekend! >> >> The remaining schedule for WF10 is as follows: >> >> WildFly 10 CR1 - September 9th >> WildFly 10 CR2 (if needed) - September 16th >> WildFly 10 Final - October 8th (contigent on certification) >> >> So that means we have 26 days (17 workdays left) to: >> >> - Stabilize features brought in during Alpha/Beta cycle >> - Finish/polish compatibility (transformers, management ops, etc) >> - Upgrade all components to Final (preferable) or CR (exceptional) >> - Fix broken and/or intermittent tests relating to the above >> - Address any other loose ends >> >> We should avoid (if possible) introducing new major features to allow for enough time to do the above. Let me know ASAP if thats a problem. >> >> Thanks! >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From brian.stansberry at redhat.com Thu Aug 13 21:02:49 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 13 Aug 2015 20:02:49 -0500 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55CCB1C6.9030106@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> <55CC38BF.8050106@redhat.com> <55CCB1C6.9030106@redhat.com> Message-ID: <55CD3E39.9080104@redhat.com> On 8/13/15 10:03 AM, Brian Stansberry wrote: > On 8/13/15 3:11 AM, Stuart Douglas wrote: >> >> >> On Thu, 13 Aug 2015 at 16:27 Ladislav Thon > > wrote: >> >> >> > The approach I took was to add the warnings to the describe-migration >> > op, and when running the migrate op make the describe-migration >> > operation the first step in the composite, so the output looks like >> > this: http://pastebin.com/B01KNAHX >> >> The fact that it's a composite operation makes the output a bit cryptic >> (step-X?), but otherwise I think it's actually good. >> >> I guess that only handling the warnings in :describe-migration makes the >> implementation easier (not sure?) and printing :describe-migration as a >> part of :migrate makes sense too, precisely because it shows the steps >> that are performed. >> >> So my only objection would be those cryptic "step-X" names, but I guess >> that we can live with that (if all :migrate operations took the same >> approach; inconsistency wouldn't really help here). >> >> >> That is because this is implemented as a composite operation, AFAIK >> there is lots of special handing for composite ops, so I don't think we >> want to be implementing our own one with different output just for this >> case. >> >> I could be wrong though, this is not really my area, Brian will know more. >> > > In the success case, I don't see the point of outputting "step-2" => > {"outcome" => "success"}, "step-3" => {"outcome" => "success"}, etc. > > In the failure case though, having an intelligible failure-description > is important. And the composite op handler may be getting in your way there > > Instead of writing more text, I'll write some code to illustrate some > thoughts and post back later. > Here's what I was thinking. [1] is a change to break out the step registration stuff CompositeOperationHandler does into a utility method, with a couple other variants added that are better suited for use by other OSHs. Basically, it lets you pass in a Map of ops and a holder map of response nodes, and it will add the steps and populate the response node map. (You can optionally pre-populate the response node map. There's also a variant that uses lists instead of maps in case that's more convenient.) Using that, the response nodes for the added ops don't have to directly appear in the overall operation response. Instead the migrate op handler can hold a ref to them and in its ResultHandler use them to format an understandable response. The top two commits in [2] are an example tweak to the current WebMigrationOp in master to illustrate use of this. [1] https://github.com/wildfly/wildfly-core/pull/956 [2] https://github.com/bstansberry/wildfly/tree/help-migrate-multistep >> Stuart >> >> >> LT >> _______________________________________________ >> 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 stuart.w.douglas at gmail.com Fri Aug 14 02:32:54 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Fri, 14 Aug 2015 06:32:54 +0000 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55CD3E39.9080104@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> <55CC38BF.8050106@redhat.com> <55CCB1C6.9030106@redhat.com> <55CD3E39.9080104@redhat.com> Message-ID: I have a PR that builds on Brian's work for the web migrate op: https://github.com/wildfly/wildfly/pull/7931 Output is: Standard EAP config (no warnings or errors): [standalone at localhost:9999 /] /subsystem=web:migrate { "outcome" => "success", "result" => {"migration-warnings" => []} } Success with a warning (in this case due to an invalid protocol attribute on a connector): [standalone at localhost:9999 /] /subsystem=web:migrate { "outcome" => "success", "result" => {"migration-warnings" => ["WFLYWEB0002: Could not migrate resource { \"protocol\" => \"INVALID\", \"scheme\" => \"http\", \"socket-binding\" => \"ajp\", \"enable-lookups\" => undefined, \"proxy-binding\" => undefined, \"proxy-name\" => undefined, \"proxy-port\" => undefined, \"redirect-binding\" => undefined, \"redirect-port\" => undefined, \"secure\" => undefined, \"max-post-size\" => undefined, \"max-save-post-size\" => undefined, \"enabled\" => undefined, \"executor\" => undefined, \"max-connections\" => undefined, \"virtual-server\" => undefined, \"name\" => \"ajp\", \"operation\" => \"add\", \"address\" => [ (\"subsystem\" => \"web\"), (\"connector\" => \"ajp\") ] }"]} } Failed OP: [standalone at localhost:9999 /] /subsystem=web:migrate { "outcome" => "failed", "result" => { "migration-warnings" => [], "migration-error" => { "operation" => { "operation" => "add", "address" => [ ("subsystem" => "undertow"), ("server" => "default-server"), ("ajp-listener" => "ajp") ], "socket-binding" => "ajp", "secure" => undefined, "redirect-socket" => undefined, "enabled" => undefined, "resolve-peer-address" => undefined, "max-post-size" => undefined, "max-connections" => "sadfadsfasdgasdfg", "operation-headers" => { "caller-type" => "user", "access-mechanism" => "NATIVE" }, "worker" => undefined, "buffer-pool" => undefined, "disallowed-methods" => undefined, "max-header-size" => undefined, "buffer-pipelined-data" => undefined, "max-parameters" => undefined, "max-headers" => undefined, "max-cookies" => undefined, "allow-encoded-slash" => undefined, "decode-url" => undefined, "url-charset" => undefined, "always-set-keep-alive" => undefined, "max-buffered-request-size" => undefined, "record-request-start-time" => undefined, "allow-equals-in-cookie-value" => undefined, "no-request-timeout" => undefined, "request-parse-timeout" => undefined, "tcp-backlog" => undefined, "receive-buffer" => undefined, "send-buffer" => undefined, "tcp-keep-alive" => undefined, "read-timeout" => undefined, "write-timeout" => undefined }, "result" => { "outcome" => "failed", "failure-description" => "WFLYCTL0097: Wrong type for max-connections. Expected [INT] but was STRING", "rolled-back" => true } } }, "rolled-back" => true } Stuart On Fri, 14 Aug 2015 at 11:03 Brian Stansberry wrote: > On 8/13/15 10:03 AM, Brian Stansberry wrote: > > On 8/13/15 3:11 AM, Stuart Douglas wrote: > >> > >> > >> On Thu, 13 Aug 2015 at 16:27 Ladislav Thon >> > wrote: > >> > >> > >> > The approach I took was to add the warnings to the > describe-migration > >> > op, and when running the migrate op make the describe-migration > >> > operation the first step in the composite, so the output looks > like > >> > this: http://pastebin.com/B01KNAHX > >> > >> The fact that it's a composite operation makes the output a bit > cryptic > >> (step-X?), but otherwise I think it's actually good. > >> > >> I guess that only handling the warnings in :describe-migration > makes the > >> implementation easier (not sure?) and printing :describe-migration > as a > >> part of :migrate makes sense too, precisely because it shows the > steps > >> that are performed. > >> > >> So my only objection would be those cryptic "step-X" names, but I > guess > >> that we can live with that (if all :migrate operations took the > same > >> approach; inconsistency wouldn't really help here). > >> > >> > >> That is because this is implemented as a composite operation, AFAIK > >> there is lots of special handing for composite ops, so I don't think we > >> want to be implementing our own one with different output just for this > >> case. > >> > >> I could be wrong though, this is not really my area, Brian will know > more. > >> > > > > In the success case, I don't see the point of outputting "step-2" => > > {"outcome" => "success"}, "step-3" => {"outcome" => "success"}, etc. > > > > In the failure case though, having an intelligible failure-description > > is important. And the composite op handler may be getting in your way > there > > > > Instead of writing more text, I'll write some code to illustrate some > > thoughts and post back later. > > > > Here's what I was thinking. > > [1] is a change to break out the step registration stuff > CompositeOperationHandler does into a utility method, with a couple > other variants added that are better suited for use by other OSHs. > > Basically, it lets you pass in a Map of ops and a holder map of response > nodes, and it will add the steps and populate the response node map. > (You can optionally pre-populate the response node map. There's also a > variant that uses lists instead of maps in case that's more convenient.) > > Using that, the response nodes for the added ops don't have to directly > appear in the overall operation response. Instead the migrate op handler > can hold a ref to them and in its ResultHandler use them to format an > understandable response. > > The top two commits in [2] are an example tweak to the current > WebMigrationOp in master to illustrate use of this. > > [1] https://github.com/wildfly/wildfly-core/pull/956 > > [2] https://github.com/bstansberry/wildfly/tree/help-migrate-multistep > > >> Stuart > >> > >> > >> LT > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150814/84dcb80d/attachment.html From lthon at redhat.com Fri Aug 14 02:56:51 2015 From: lthon at redhat.com (Ladislav Thon) Date: Fri, 14 Aug 2015 08:56:51 +0200 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> <55CC38BF.8050106@redhat.com> <55CCB1C6.9030106@redhat.com> <55CD3E39.9080104@redhat.com> Message-ID: <55CD9133.5010509@redhat.com> Looks good! > [standalone at localhost:9999 /] /subsystem=web:migrate > { > "outcome" => "success", > "result" => {"migration-warnings" => []} > } I wonder what happened to showing the name of the new subsystem and its version. Not that I'd insist on it, but it made sense :-) LT From stuart.w.douglas at gmail.com Fri Aug 14 03:22:12 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Fri, 14 Aug 2015 07:22:12 +0000 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55CD9133.5010509@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> <55CC38BF.8050106@redhat.com> <55CCB1C6.9030106@redhat.com> <55CD3E39.9080104@redhat.com> <55CD9133.5010509@redhat.com> Message-ID: On Fri, 14 Aug 2015 at 16:57 Ladislav Thon wrote: > Looks good! > > > [standalone at localhost:9999 /] /subsystem=web:migrate > > { > > "outcome" => "success", > > "result" => {"migration-warnings" => []} > > } > > I wonder what happened to showing the name of the new subsystem and its > version. Not that I'd insist on it, but it made sense :-) > In the web case we actually add two (IO and Undertow). Personally I don't think it is necessary, if they want to see what the op does they should use the describe op. Stuart > > LT > _______________________________________________ > 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/20150814/9567a074/attachment-0001.html From brian.stansberry at redhat.com Fri Aug 14 11:01:33 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 14 Aug 2015 10:01:33 -0500 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> <55CC38BF.8050106@redhat.com> <55CCB1C6.9030106@redhat.com> <55CD3E39.9080104@redhat.com> Message-ID: <55CE02CD.4040003@redhat.com> Looks good. Do we want migration-warnings=-[] in the success case, or just omit it? I don't have a strong preference either way. Seeing all the details in the failure case made me nervous about RBAC. But I think the key there is in the read of the subsystem that goes to produce the ops. We should test that that fails if the caller is not able to address some child resource or if the caller is not able to read some attribute value. If we know the caller can read the entire subsystem then it is safe to provide details of any failure on the writes, since it is the same data. Once everything is clear we should work out a way to have shared code so this stuff has a higher guarantee of consistency across subsystems. On 8/14/15 1:32 AM, Stuart Douglas wrote: > I have a PR that builds on Brian's work for the web migrate op: > https://github.com/wildfly/wildfly/pull/7931 > > Output is: > > Standard EAP config (no warnings or errors): > > [standalone at localhost:9999 /] /subsystem=web:migrate > { > "outcome" => "success", > "result" => {"migration-warnings" => []} > } > > Success with a warning (in this case due to an invalid protocol > attribute on a connector): > > [standalone at localhost:9999 /] /subsystem=web:migrate > { > "outcome" => "success", > "result" => {"migration-warnings" => ["WFLYWEB0002: Could not > migrate resource { > \"protocol\" => \"INVALID\", > \"scheme\" => \"http\", > \"socket-binding\" => \"ajp\", > \"enable-lookups\" => undefined, > \"proxy-binding\" => undefined, > \"proxy-name\" => undefined, > \"proxy-port\" => undefined, > \"redirect-binding\" => undefined, > \"redirect-port\" => undefined, > \"secure\" => undefined, > \"max-post-size\" => undefined, > \"max-save-post-size\" => undefined, > \"enabled\" => undefined, > \"executor\" => undefined, > \"max-connections\" => undefined, > \"virtual-server\" => undefined, > \"name\" => \"ajp\", > \"operation\" => \"add\", > \"address\" => [ > (\"subsystem\" => \"web\"), > (\"connector\" => \"ajp\") > ] > }"]} > } > > Failed OP: > > [standalone at localhost:9999 /] /subsystem=web:migrate > { > "outcome" => "failed", > "result" => { > "migration-warnings" => [], > "migration-error" => { > "operation" => { > "operation" => "add", > "address" => [ > ("subsystem" => "undertow"), > ("server" => "default-server"), > ("ajp-listener" => "ajp") > ], > "socket-binding" => "ajp", > "secure" => undefined, > "redirect-socket" => undefined, > "enabled" => undefined, > "resolve-peer-address" => undefined, > "max-post-size" => undefined, > "max-connections" => "sadfadsfasdgasdfg", > "operation-headers" => { > "caller-type" => "user", > "access-mechanism" => "NATIVE" > }, > "worker" => undefined, > "buffer-pool" => undefined, > "disallowed-methods" => undefined, > "max-header-size" => undefined, > "buffer-pipelined-data" => undefined, > "max-parameters" => undefined, > "max-headers" => undefined, > "max-cookies" => undefined, > "allow-encoded-slash" => undefined, > "decode-url" => undefined, > "url-charset" => undefined, > "always-set-keep-alive" => undefined, > "max-buffered-request-size" => undefined, > "record-request-start-time" => undefined, > "allow-equals-in-cookie-value" => undefined, > "no-request-timeout" => undefined, > "request-parse-timeout" => undefined, > "tcp-backlog" => undefined, > "receive-buffer" => undefined, > "send-buffer" => undefined, > "tcp-keep-alive" => undefined, > "read-timeout" => undefined, > "write-timeout" => undefined > }, > "result" => { > "outcome" => "failed", > "failure-description" => "WFLYCTL0097: Wrong type for > max-connections. Expected [INT] but was STRING", > "rolled-back" => true > } > } > }, > "rolled-back" => true > } > > Stuart > > > > > On Fri, 14 Aug 2015 at 11:03 Brian Stansberry > > wrote: > > On 8/13/15 10:03 AM, Brian Stansberry wrote: > > On 8/13/15 3:11 AM, Stuart Douglas wrote: > >> > >> > >> On Thu, 13 Aug 2015 at 16:27 Ladislav Thon > >> >> wrote: > >> > >> > >> > The approach I took was to add the warnings to the > describe-migration > >> > op, and when running the migrate op make the > describe-migration > >> > operation the first step in the composite, so the output > looks like > >> > this: http://pastebin.com/B01KNAHX > >> > >> The fact that it's a composite operation makes the output a > bit cryptic > >> (step-X?), but otherwise I think it's actually good. > >> > >> I guess that only handling the warnings in > :describe-migration makes the > >> implementation easier (not sure?) and printing > :describe-migration as a > >> part of :migrate makes sense too, precisely because it > shows the steps > >> that are performed. > >> > >> So my only objection would be those cryptic "step-X" names, > but I guess > >> that we can live with that (if all :migrate operations took > the same > >> approach; inconsistency wouldn't really help here). > >> > >> > >> That is because this is implemented as a composite operation, AFAIK > >> there is lots of special handing for composite ops, so I don't > think we > >> want to be implementing our own one with different output just > for this > >> case. > >> > >> I could be wrong though, this is not really my area, Brian will > know more. > >> > > > > In the success case, I don't see the point of outputting "step-2" => > > {"outcome" => "success"}, "step-3" => {"outcome" => "success"}, etc. > > > > In the failure case though, having an intelligible > failure-description > > is important. And the composite op handler may be getting in your > way there > > > > Instead of writing more text, I'll write some code to illustrate some > > thoughts and post back later. > > > > Here's what I was thinking. > > [1] is a change to break out the step registration stuff > CompositeOperationHandler does into a utility method, with a couple > other variants added that are better suited for use by other OSHs. > > Basically, it lets you pass in a Map of ops and a holder map of response > nodes, and it will add the steps and populate the response node map. > (You can optionally pre-populate the response node map. There's also a > variant that uses lists instead of maps in case that's more convenient.) > > Using that, the response nodes for the added ops don't have to directly > appear in the overall operation response. Instead the migrate op handler > can hold a ref to them and in its ResultHandler use them to format an > understandable response. > > The top two commits in [2] are an example tweak to the current > WebMigrationOp in master to illustrate use of this. > > [1] https://github.com/wildfly/wildfly-core/pull/956 > > [2] https://github.com/bstansberry/wildfly/tree/help-migrate-multistep > > >> Stuart > >> > >> > >> LT > >> _______________________________________________ > >> 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 > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From dennis at gesker.com Fri Aug 14 11:53:47 2015 From: dennis at gesker.com (Dennis Gesker) Date: Fri, 14 Aug 2015 09:53:47 -0600 Subject: [wildfly-dev] stream parallel Message-ID: Hello List: Just looking for a best practice recommendation on new functional capabilities when WildFly is running atop Java 8. My understanding is that when you wish to do a concurrent operation one is best served using the functionality built into the EE container rather than the JVM directly. This view may be incorrect or outdated. Does it still hold true? Should stream parallel be avoided for the time being in Java EE applications? Should one expect that at some point there will be an EE level set of classes for stream parallel? Perhaps something like "ManagedStream" -- sort of like the current ManagedExecutorService for Callables/Runnables provided by the container -- in the future? BTW, I tried posting the above on jboss-user a few days ago but didn't get a bite. Has a wildfly-user been created to replace jboss-user? Thanks Dennis -- [image: https://www.facebook.com/gesker] [image: https://twitter.com/gesker] [image: http://gesker.wordpress.com] [image: http://www.gesker.com] "Be without fear in the face of your enemies. Be brave and upright that God may love thee. Speak the truth always, even if it leads to your death. Safeguard the helpless and do no wrong ? that is your oath.? -The Knight?s Oath (Kingdom of Heaven) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150814/06faf3bb/attachment.html From stuart.w.douglas at gmail.com Fri Aug 14 20:23:35 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Sat, 15 Aug 2015 00:23:35 +0000 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55CE02CD.4040003@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> <55CC38BF.8050106@redhat.com> <55CCB1C6.9030106@redhat.com> <55CD3E39.9080104@redhat.com> <55CE02CD.4040003@redhat.com> Message-ID: On Sat, 15 Aug 2015 at 01:01 Brian Stansberry wrote: > Looks good. > > Do we want migration-warnings=-[] in the success case, or just omit it? > I don't have a strong preference either way. > I have changed it so this will not be displayed. > > Seeing all the details in the failure case made me nervous about RBAC. > But I think the key there is in the read of the subsystem that goes to > produce the ops. We should test that that fails if the caller is not > able to address some child resource or if the caller is not able to read > some attribute value. > Should this hold up the PR, or is this a task for later? Stuart > > If we know the caller can read the entire subsystem then it is safe to > provide details of any failure on the writes, since it is the same data. > > Once everything is clear we should work out a way to have shared code so > this stuff has a higher guarantee of consistency across subsystems. > > On 8/14/15 1:32 AM, Stuart Douglas wrote: > > I have a PR that builds on Brian's work for the web migrate op: > > https://github.com/wildfly/wildfly/pull/7931 > > > > Output is: > > > > Standard EAP config (no warnings or errors): > > > > [standalone at localhost:9999 /] /subsystem=web:migrate > > { > > "outcome" => "success", > > "result" => {"migration-warnings" => []} > > } > > > > Success with a warning (in this case due to an invalid protocol > > attribute on a connector): > > > > [standalone at localhost:9999 /] /subsystem=web:migrate > > { > > "outcome" => "success", > > "result" => {"migration-warnings" => ["WFLYWEB0002: Could not > > migrate resource { > > \"protocol\" => \"INVALID\", > > \"scheme\" => \"http\", > > \"socket-binding\" => \"ajp\", > > \"enable-lookups\" => undefined, > > \"proxy-binding\" => undefined, > > \"proxy-name\" => undefined, > > \"proxy-port\" => undefined, > > \"redirect-binding\" => undefined, > > \"redirect-port\" => undefined, > > \"secure\" => undefined, > > \"max-post-size\" => undefined, > > \"max-save-post-size\" => undefined, > > \"enabled\" => undefined, > > \"executor\" => undefined, > > \"max-connections\" => undefined, > > \"virtual-server\" => undefined, > > \"name\" => \"ajp\", > > \"operation\" => \"add\", > > \"address\" => [ > > (\"subsystem\" => \"web\"), > > (\"connector\" => \"ajp\") > > ] > > }"]} > > } > > > > Failed OP: > > > > [standalone at localhost:9999 /] /subsystem=web:migrate > > { > > "outcome" => "failed", > > "result" => { > > "migration-warnings" => [], > > "migration-error" => { > > "operation" => { > > "operation" => "add", > > "address" => [ > > ("subsystem" => "undertow"), > > ("server" => "default-server"), > > ("ajp-listener" => "ajp") > > ], > > "socket-binding" => "ajp", > > "secure" => undefined, > > "redirect-socket" => undefined, > > "enabled" => undefined, > > "resolve-peer-address" => undefined, > > "max-post-size" => undefined, > > "max-connections" => "sadfadsfasdgasdfg", > > "operation-headers" => { > > "caller-type" => "user", > > "access-mechanism" => "NATIVE" > > }, > > "worker" => undefined, > > "buffer-pool" => undefined, > > "disallowed-methods" => undefined, > > "max-header-size" => undefined, > > "buffer-pipelined-data" => undefined, > > "max-parameters" => undefined, > > "max-headers" => undefined, > > "max-cookies" => undefined, > > "allow-encoded-slash" => undefined, > > "decode-url" => undefined, > > "url-charset" => undefined, > > "always-set-keep-alive" => undefined, > > "max-buffered-request-size" => undefined, > > "record-request-start-time" => undefined, > > "allow-equals-in-cookie-value" => undefined, > > "no-request-timeout" => undefined, > > "request-parse-timeout" => undefined, > > "tcp-backlog" => undefined, > > "receive-buffer" => undefined, > > "send-buffer" => undefined, > > "tcp-keep-alive" => undefined, > > "read-timeout" => undefined, > > "write-timeout" => undefined > > }, > > "result" => { > > "outcome" => "failed", > > "failure-description" => "WFLYCTL0097: Wrong type for > > max-connections. Expected [INT] but was STRING", > > "rolled-back" => true > > } > > } > > }, > > "rolled-back" => true > > } > > > > Stuart > > > > > > > > > > On Fri, 14 Aug 2015 at 11:03 Brian Stansberry > > > > wrote: > > > > On 8/13/15 10:03 AM, Brian Stansberry wrote: > > > On 8/13/15 3:11 AM, Stuart Douglas wrote: > > >> > > >> > > >> On Thu, 13 Aug 2015 at 16:27 Ladislav Thon > > > >> >> wrote: > > >> > > >> > > >> > The approach I took was to add the warnings to the > > describe-migration > > >> > op, and when running the migrate op make the > > describe-migration > > >> > operation the first step in the composite, so the output > > looks like > > >> > this: http://pastebin.com/B01KNAHX > > >> > > >> The fact that it's a composite operation makes the output a > > bit cryptic > > >> (step-X?), but otherwise I think it's actually good. > > >> > > >> I guess that only handling the warnings in > > :describe-migration makes the > > >> implementation easier (not sure?) and printing > > :describe-migration as a > > >> part of :migrate makes sense too, precisely because it > > shows the steps > > >> that are performed. > > >> > > >> So my only objection would be those cryptic "step-X" names, > > but I guess > > >> that we can live with that (if all :migrate operations took > > the same > > >> approach; inconsistency wouldn't really help here). > > >> > > >> > > >> That is because this is implemented as a composite operation, > AFAIK > > >> there is lots of special handing for composite ops, so I don't > > think we > > >> want to be implementing our own one with different output just > > for this > > >> case. > > >> > > >> I could be wrong though, this is not really my area, Brian will > > know more. > > >> > > > > > > In the success case, I don't see the point of outputting "step-2" > => > > > {"outcome" => "success"}, "step-3" => {"outcome" => "success"}, > etc. > > > > > > In the failure case though, having an intelligible > > failure-description > > > is important. And the composite op handler may be getting in your > > way there > > > > > > Instead of writing more text, I'll write some code to illustrate > some > > > thoughts and post back later. > > > > > > > Here's what I was thinking. > > > > [1] is a change to break out the step registration stuff > > CompositeOperationHandler does into a utility method, with a couple > > other variants added that are better suited for use by other OSHs. > > > > Basically, it lets you pass in a Map of ops and a holder map of > response > > nodes, and it will add the steps and populate the response node map. > > (You can optionally pre-populate the response node map. There's also > a > > variant that uses lists instead of maps in case that's more > convenient.) > > > > Using that, the response nodes for the added ops don't have to > directly > > appear in the overall operation response. Instead the migrate op > handler > > can hold a ref to them and in its ResultHandler use them to format an > > understandable response. > > > > The top two commits in [2] are an example tweak to the current > > WebMigrationOp in master to illustrate use of this. > > > > [1] https://github.com/wildfly/wildfly-core/pull/956 > > > > [2] > https://github.com/bstansberry/wildfly/tree/help-migrate-multistep > > > > >> Stuart > > >> > > >> > > >> LT > > >> _______________________________________________ > > >> 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 > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150815/52d534a0/attachment-0001.html From brian.stansberry at redhat.com Mon Aug 17 09:36:11 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 17 Aug 2015 08:36:11 -0500 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> <55CC38BF.8050106@redhat.com> <55CCB1C6.9030106@redhat.com> <55CD3E39.9080104@redhat.com> <55CE02CD.4040003@redhat.com> Message-ID: <55D1E34B.70601@redhat.com> On 8/14/15 7:23 PM, Stuart Douglas wrote: > > > On Sat, 15 Aug 2015 at 01:01 Brian Stansberry > > wrote: > > Looks good. > > Do we want migration-warnings=-[] in the success case, or just omit it? > I don't have a strong preference either way. > > > I have changed it so this will not be displayed. > > > Seeing all the details in the failure case made me nervous about RBAC. > But I think the key there is in the read of the subsystem that goes to > produce the ops. We should test that that fails if the caller is not > able to address some child resource or if the caller is not able to read > some attribute value. > > > Should this hold up the PR, or is this a task for later? > No reason to hold up the PR. > Stuart > > > If we know the caller can read the entire subsystem then it is safe to > provide details of any failure on the writes, since it is the same data. > > Once everything is clear we should work out a way to have shared code so > this stuff has a higher guarantee of consistency across subsystems. > > On 8/14/15 1:32 AM, Stuart Douglas wrote: > > I have a PR that builds on Brian's work for the web migrate op: > > https://github.com/wildfly/wildfly/pull/7931 > > > > Output is: > > > > Standard EAP config (no warnings or errors): > > > > [standalone at localhost:9999 /] /subsystem=web:migrate > > { > > "outcome" => "success", > > "result" => {"migration-warnings" => []} > > } > > > > Success with a warning (in this case due to an invalid protocol > > attribute on a connector): > > > > [standalone at localhost:9999 /] /subsystem=web:migrate > > { > > "outcome" => "success", > > "result" => {"migration-warnings" => ["WFLYWEB0002: Could not > > migrate resource { > > \"protocol\" => \"INVALID\", > > \"scheme\" => \"http\", > > \"socket-binding\" => \"ajp\", > > \"enable-lookups\" => undefined, > > \"proxy-binding\" => undefined, > > \"proxy-name\" => undefined, > > \"proxy-port\" => undefined, > > \"redirect-binding\" => undefined, > > \"redirect-port\" => undefined, > > \"secure\" => undefined, > > \"max-post-size\" => undefined, > > \"max-save-post-size\" => undefined, > > \"enabled\" => undefined, > > \"executor\" => undefined, > > \"max-connections\" => undefined, > > \"virtual-server\" => undefined, > > \"name\" => \"ajp\", > > \"operation\" => \"add\", > > \"address\" => [ > > (\"subsystem\" => \"web\"), > > (\"connector\" => \"ajp\") > > ] > > }"]} > > } > > > > Failed OP: > > > > [standalone at localhost:9999 /] /subsystem=web:migrate > > { > > "outcome" => "failed", > > "result" => { > > "migration-warnings" => [], > > "migration-error" => { > > "operation" => { > > "operation" => "add", > > "address" => [ > > ("subsystem" => "undertow"), > > ("server" => "default-server"), > > ("ajp-listener" => "ajp") > > ], > > "socket-binding" => "ajp", > > "secure" => undefined, > > "redirect-socket" => undefined, > > "enabled" => undefined, > > "resolve-peer-address" => undefined, > > "max-post-size" => undefined, > > "max-connections" => "sadfadsfasdgasdfg", > > "operation-headers" => { > > "caller-type" => "user", > > "access-mechanism" => "NATIVE" > > }, > > "worker" => undefined, > > "buffer-pool" => undefined, > > "disallowed-methods" => undefined, > > "max-header-size" => undefined, > > "buffer-pipelined-data" => undefined, > > "max-parameters" => undefined, > > "max-headers" => undefined, > > "max-cookies" => undefined, > > "allow-encoded-slash" => undefined, > > "decode-url" => undefined, > > "url-charset" => undefined, > > "always-set-keep-alive" => undefined, > > "max-buffered-request-size" => undefined, > > "record-request-start-time" => undefined, > > "allow-equals-in-cookie-value" => undefined, > > "no-request-timeout" => undefined, > > "request-parse-timeout" => undefined, > > "tcp-backlog" => undefined, > > "receive-buffer" => undefined, > > "send-buffer" => undefined, > > "tcp-keep-alive" => undefined, > > "read-timeout" => undefined, > > "write-timeout" => undefined > > }, > > "result" => { > > "outcome" => "failed", > > "failure-description" => "WFLYCTL0097: Wrong > type for > > max-connections. Expected [INT] but was STRING", > > "rolled-back" => true > > } > > } > > }, > > "rolled-back" => true > > } > > > > Stuart > > > > > > > > > > On Fri, 14 Aug 2015 at 11:03 Brian Stansberry > > > >> wrote: > > > > On 8/13/15 10:03 AM, Brian Stansberry wrote: > > > On 8/13/15 3:11 AM, Stuart Douglas wrote: > > >> > > >> > > >> On Thu, 13 Aug 2015 at 16:27 Ladislav Thon > > > > > > >> > >>> wrote: > > >> > > >> > > >> > The approach I took was to add the warnings to the > > describe-migration > > >> > op, and when running the migrate op make the > > describe-migration > > >> > operation the first step in the composite, so the > output > > looks like > > >> > this: http://pastebin.com/B01KNAHX > > >> > > >> The fact that it's a composite operation makes the > output a > > bit cryptic > > >> (step-X?), but otherwise I think it's actually good. > > >> > > >> I guess that only handling the warnings in > > :describe-migration makes the > > >> implementation easier (not sure?) and printing > > :describe-migration as a > > >> part of :migrate makes sense too, precisely because it > > shows the steps > > >> that are performed. > > >> > > >> So my only objection would be those cryptic "step-X" > names, > > but I guess > > >> that we can live with that (if all :migrate > operations took > > the same > > >> approach; inconsistency wouldn't really help here). > > >> > > >> > > >> That is because this is implemented as a composite > operation, AFAIK > > >> there is lots of special handing for composite ops, so I > don't > > think we > > >> want to be implementing our own one with different output > just > > for this > > >> case. > > >> > > >> I could be wrong though, this is not really my area, > Brian will > > know more. > > >> > > > > > > In the success case, I don't see the point of outputting > "step-2" => > > > {"outcome" => "success"}, "step-3" => {"outcome" => > "success"}, etc. > > > > > > In the failure case though, having an intelligible > > failure-description > > > is important. And the composite op handler may be getting > in your > > way there > > > > > > Instead of writing more text, I'll write some code to > illustrate some > > > thoughts and post back later. > > > > > > > Here's what I was thinking. > > > > [1] is a change to break out the step registration stuff > > CompositeOperationHandler does into a utility method, with a > couple > > other variants added that are better suited for use by other > OSHs. > > > > Basically, it lets you pass in a Map of ops and a holder map > of response > > nodes, and it will add the steps and populate the response > node map. > > (You can optionally pre-populate the response node map. > There's also a > > variant that uses lists instead of maps in case that's more > convenient.) > > > > Using that, the response nodes for the added ops don't have > to directly > > appear in the overall operation response. Instead the migrate > op handler > > can hold a ref to them and in its ResultHandler use them to > format an > > understandable response. > > > > The top two commits in [2] are an example tweak to the current > > WebMigrationOp in master to illustrate use of this. > > > > [1] https://github.com/wildfly/wildfly-core/pull/956 > > > > [2] > https://github.com/bstansberry/wildfly/tree/help-migrate-multistep > > > > >> Stuart > > >> > > >> > > >> LT > > >> _______________________________________________ > > >> 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 > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jmesnil at redhat.com Tue Aug 18 05:14:41 2015 From: jmesnil at redhat.com (Jeff Mesnil) Date: Tue, 18 Aug 2015 11:14:41 +0200 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55C8BE51.4030203@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> Message-ID: <2B558DD7-C490-4D31-90B7-A126BBC2B468@redhat.com> Soory for the late reply, I was in PTO. > On 10 Aug 2015, at 17:08, Brian Stansberry wrote: >> 4. What should happen if some other subsystem is expecting definition of element in new migrated configuration but it's not there after migration? >> -- For example ejb subsystem has by default "activemq-ra" as default resource adapter for MDBs and migrated Artemis subsystem will not contain it. >> As brian said, the migration must start with a valid legacy configuration. In your case, let?s say you start with WildFly 9 configuration. The default resource adapter name in the ejb subsystem is ?hornetq-ra? and there is a corresponding pooled-connection-factory with that name in the (legacy) messaging subsystem. When you migrate the messaging subsystem, a new pooled-connection-factory will be added in the new messaging-activemq subsystem with the same name "hornetq-ra?. So the RA has changed (from HornetQ to Artemis) but its name is the same and the ejb subsystem will work as expected after migration. -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From jmesnil at redhat.com Tue Aug 18 05:28:22 2015 From: jmesnil at redhat.com (Jeff Mesnil) Date: Tue, 18 Aug 2015 11:28:22 +0200 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> <55CC38BF.8050106@redhat.com> <55CCB1C6.9030106@redhat.com> <55CD3E39.9080104@redhat.com> Message-ID: <34531B79-C8D6-4532-BABF-B1E643DBCF22@redhat.com> > On 14 Aug 2015, at 08:32, Stuart Douglas wrote: > > I have a PR that builds on Brian's work for the web migrate op: https://github.com/wildfly/wildfly/pull/7931 > > Output is: > > Standard EAP config (no warnings or errors): > > [standalone at localhost:9999 /] /subsystem=web:migrate > { > "outcome" => "success", > "result" => {"migration-warnings" => []} > } I wonder if we should generalize this and move the warnings outside the result. The warnings could go in the response headers for example as a LIST of STRING. The result output would be something like: { "outcome" : "success", "result" : { ? } "response-headers" : [{ "warnings" : [ ?warning 1?, ?warning 2? ] }] } This would help our clients (CLI and HAL) handle them appropriately regardless of the invoked operation. And this would not ?pollute? the operation?s result type. jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From brian.stansberry at redhat.com Tue Aug 18 15:15:52 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 18 Aug 2015 14:15:52 -0500 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <34531B79-C8D6-4532-BABF-B1E643DBCF22@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <55C998BE.7090309@redhat.com> <55CA03F2.5000508@redhat.com> <55CC38BF.8050106@redhat.com> <55CCB1C6.9030106@redhat.com> <55CD3E39.9080104@redhat.com> <34531B79-C8D6-4532-BABF-B1E643DBCF22@redhat.com> Message-ID: <55D38468.9040906@redhat.com> On 8/18/15 4:28 AM, Jeff Mesnil wrote: > >> On 14 Aug 2015, at 08:32, Stuart Douglas wrote: >> >> I have a PR that builds on Brian's work for the web migrate op: https://github.com/wildfly/wildfly/pull/7931 >> >> Output is: >> >> Standard EAP config (no warnings or errors): >> >> [standalone at localhost:9999 /] /subsystem=web:migrate >> { >> "outcome" => "success", >> "result" => {"migration-warnings" => []} >> } > > I wonder if we should generalize this and move the warnings outside the result. > The warnings could go in the response headers for example as a LIST of STRING. > > The result output would be something like: > > { > "outcome" : "success", > "result" : { ? } > "response-headers" : [{ > "warnings" : [ > ?warning 1?, > ?warning 2? > ] > }] > } > > This would help our clients (CLI and HAL) handle them appropriately regardless of the invoked operation. And this would not ?pollute? the operation?s result type. > A general warning response header sounds ok, but I don't think we have time to implement that for WF 10. It's easy enough for the simple case, but less so for stuff like composite ops that result in updates to multiple processes in a domain. > jeff > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From kap4020 at gmail.com Wed Aug 19 09:38:49 2015 From: kap4020 at gmail.com (Karl Pietrzak) Date: Wed, 19 Aug 2015 09:38:49 -0400 Subject: [wildfly-dev] clarification on why Wildfly versions are increasing so quickly Message-ID: Hi everyone! First off, kudos to everyone for a great product! Secondly, I'm wondering if someone could explain to me the significance of the quick succession of Wildfly version upgrades: from 8 -> 9 -> 10 (soon). It seemed like we were on JBoss 7.x for a long time, and now the top link at http://wildfly.org/downloads/ is actually the Wildfly 10.x beta. Does this represent: 1. a sudden increase in contributions and feature work? 2. shift in marketing (i.e., no underlying tech changes) 3. something else Our concern is that this represents some instability / internal dynamics / change in policy that would encourage us to visit other app servers. Thank you! -- Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150819/b089403a/attachment.html From arjan.tijms at gmail.com Wed Aug 19 10:30:57 2015 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 19 Aug 2015 16:30:57 +0200 Subject: [wildfly-dev] clarification on why Wildfly versions are increasing so quickly In-Reply-To: References: Message-ID: Hi, I'm not affiliated with JBoss or Red Hat, just a user and therefor not able to give any "official answer", but as a mere user I'm not bothered much by this. WildFly versions are just milestones on the road to the next EAP version anyway. So whether you have {EAP 6, m1, m2, m3, m4, EAP 7}, or {EAP 6, wf8, wf9, wf10, EAP 7} doesn't make a lot of difference to me. >From another point of view, Chrome has been been updating major versions for every small thing for a long time now, where before browsers used to be on some major version like forever and incremented minor. It doesn't mean Chrome is making larger leaps, it's just a numbering for which no universal rules have really been set. E.g. Vendor X's version 10.12.Alpha-1.a.3 may be comparable to Vendor's Y version 0.53. Hard to compare. Kind regards, Arjan Tijms On Wed, Aug 19, 2015 at 3:38 PM, Karl Pietrzak wrote: > Hi everyone! > > First off, kudos to everyone for a great product! > > Secondly, I'm wondering if someone could explain to me the significance of > the quick succession of Wildfly version upgrades: from 8 -> 9 -> 10 (soon). > > It seemed like we were on JBoss 7.x for a long time, and now the top link at > http://wildfly.org/downloads/ is actually the Wildfly 10.x beta. > > Does this represent: > 1. a sudden increase in contributions and feature work? > 2. shift in marketing (i.e., no underlying tech changes) > 3. something else > > Our concern is that this represents some instability / internal dynamics / > change in policy that would encourage us to visit other app servers. > > Thank you! > > -- > Karl > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jmesnil at redhat.com Thu Aug 20 05:01:48 2015 From: jmesnil at redhat.com (Jeff Mesnil) Date: Thu, 20 Aug 2015 11:01:48 +0200 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <55C8BE51.4030203@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> Message-ID: <3DB85C0C-B21E-413B-B287-B94A3DC081DC@redhat.com> > On 10 Aug 2015, at 17:08, Brian Stansberry wrote: >> 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this? >> > > I think the op should fail (not just warn) if the subsystem cannot be > properly migrated. > > That said, we need to be careful about having the scope of the handlers > grow too large, forcing handlers for one subsystem to be tightly coupled > to the implementation details of other subsystems or the kernel. Your > questions 2-4 relate to this kind of scope question. If the coupling > between different parts of the system starts to get too deep, IMO it > starts to move beyond the intended scope of these operations and into > the realm of higher level tools like Red Hat's Windup tool. It's a > judgement call but my feeling is what the handlers are currently doing > (e.g. the stuff I mention in my answer to #2) is reasonable. I have a such an use case where I can?t migrate feature from the legacy messaging subsystem to the new messaging-activemq subsystem. In the legacy subsystem, HA policy is driven by 2 attributes on the hornetq-server resource (shared-store and backup which both are BOOLEAN attribute that allow expressions). In the new messaging-activemq subsystem, HA policy is configured by different child for the ha-policy resource (shared-store-slave, shared-store-master, replication-master, replication-slave and others). During the migration, I can not just read the values of the share-store and backup attributes to determine the type of ha-policy to use in the new subsystems. If they use expressions, their values are determined by the system properties set for each server. That means that with previous versions, you could use 1 single profile to have both a master and slave nodes (with different sys prop for their backup attribute). In WildFly 10, there must be 2 different profile, one with replication-master and another with replication-slave. I think this goes beyond the scope of the :migrate operation to create multiple profiles during the migration of a single subsystem. I?d prefer to warn the user that messaging HA configuration has significantly changed and he will have to review the legacy one and configure a new one. We can then use higher-level tools (such a JBoss WindUp) to help him configure the new ones. The migration sequence in that case would be: 1. call /subsystem=messaging:describe-migration to check if there are any warnings 2. if there are (e.g. about this HA stuff), run WindUp to create XML snippet (or CLI commands) corresponding to the HA stuff (I?ve no idea how WindUp can do that, so I?m just waving my hands and assume it can) 3. call /subsystem=messaging:migrate => the legacy messaging subsystem has been removed and the new messaging-activemq is present without its HA configuration 4. use the WindUp output (copy the XML snippet or execute the CLI commands) to add the new HA configuration. Is that something doable with WindUp? -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From ep.nidheesh at gmail.com Thu Aug 20 08:56:43 2015 From: ep.nidheesh at gmail.com (Nidheesh Ep) Date: Thu, 20 Aug 2015 18:26:43 +0530 Subject: [wildfly-dev] Undertow redirection issues - WildFly 8.2.0 Message-ID: Hi team, Our old customer portal was migrated to WildFly-8.2.0 from JBoss 4. We had an integration with Drupal. The ROOT.war was deployed successfully. But while accessing to the webpage(/home), the page is running into a redirect loop. Error trace: Exception handling request to /home/index.php?q=: com.caucho.quercus.QuercusModuleException: java.io.IOException: An established connection was aborted by the software in your host machine Posted this issue in the community at: https://developer.jboss.org/thread/261266?sr=inbox In stackoverflow: http://stackoverflow.com/questions/31421347/application-runs-into-a-redirect-loop-error-wildfly8 Cheers, Nidheesh -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150820/10c39721/attachment.html From jason.greene at redhat.com Thu Aug 20 14:06:20 2015 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 20 Aug 2015 13:06:20 -0500 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: <3DB85C0C-B21E-413B-B287-B94A3DC081DC@redhat.com> References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <3DB85C0C-B21E-413B-B287-B94A3DC081DC@redhat.com> Message-ID: > On Aug 20, 2015, at 4:01 AM, Jeff Mesnil wrote: > > >> On 10 Aug 2015, at 17:08, Brian Stansberry wrote: >>> 5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this? >>> >> >> I think the op should fail (not just warn) if the subsystem cannot be >> properly migrated. >> >> That said, we need to be careful about having the scope of the handlers >> grow too large, forcing handlers for one subsystem to be tightly coupled >> to the implementation details of other subsystems or the kernel. Your >> questions 2-4 relate to this kind of scope question. If the coupling >> between different parts of the system starts to get too deep, IMO it >> starts to move beyond the intended scope of these operations and into >> the realm of higher level tools like Red Hat's Windup tool. It's a >> judgement call but my feeling is what the handlers are currently doing >> (e.g. the stuff I mention in my answer to #2) is reasonable. > > I have a such an use case where I can?t migrate feature from the legacy messaging subsystem to the new messaging-activemq subsystem. > > In the legacy subsystem, HA policy is driven by 2 attributes on the hornetq-server resource (shared-store and backup which both are BOOLEAN attribute that allow expressions). > In the new messaging-activemq subsystem, HA policy is configured by different child for the ha-policy resource (shared-store-slave, shared-store-master, replication-master, replication-slave and others). > > During the migration, I can not just read the values of the share-store and backup attributes to determine the type of ha-policy to use in the new subsystems. If they use expressions, their values are determined by the system properties set for each server. That?s detectable though right? If there is no expression is it mappable? > > That means that with previous versions, you could use 1 single profile to have both a master and slave nodes (with different sys prop for their backup attribute). > In WildFly 10, there must be 2 different profile, one with replication-master and another with replication-slave. > I think this goes beyond the scope of the :migrate operation to create multiple profiles during the migration of a single subsystem. Yes creating profiles is definitely out of scope. > > I?d prefer to warn the user that messaging HA configuration has significantly changed and he will have to review the legacy one and configure a new one. > We can then use higher-level tools (such a JBoss WindUp) to help him configure the new ones. Note that Windup is likely (but not yet certain) to use the migration operations itself. > > The migration sequence in that case would be: > > 1. call /subsystem=messaging:describe-migration to check if there are any warnings > 2. if there are (e.g. about this HA stuff), run WindUp to create XML snippet (or CLI commands) > corresponding to the HA stuff (I?ve no idea how WindUp can do that, so I?m just waving my hands and > assume it can) > 3. call /subsystem=messaging:migrate > => the legacy messaging subsystem has been removed and the new messaging-activemq is present without its HA configuration > 4. use the WindUp output (copy the XML snippet or execute the CLI commands) to add the new HA configuration. > > Is that something doable with WindUp? The windup team is relying on us for domain expertise, so if it does anything super fancy in this area, beyond the operation, that would probably rely on some sort of contribution from our team. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From arun.gupta at gmail.com Fri Aug 21 21:16:44 2015 From: arun.gupta at gmail.com (Arun Gupta) Date: Fri, 21 Aug 2015 18:16:44 -0700 Subject: [wildfly-dev] Java EE + WildFly sample in Kubernetes Message-ID: In case you are interested ... Kubernetes workspace now has a sample [1] that shows how to deploy Java EE application using WildFly to Kubernetes cluster. [1] https://github.com/kubernetes/kubernetes/tree/master/examples/javaee Have a good weekend! Arun -- http://blog.arungupta.me http://twitter.com/arungupta From frank.langelage at osnanet.de Sun Aug 23 15:46:12 2015 From: frank.langelage at osnanet.de (Frank Langelage) Date: Sun, 23 Aug 2015 21:46:12 +0200 Subject: [wildfly-dev] "WildFly Test Suite: Integration - Web" fails completely since today Message-ID: <55DA2304.2080601@osnanet.de> After checkout of current Wildfly 10 CR1 sources the build with smoke tests fails. As of Friday everything was fine. Tests in error: DeploymentOverlayTestCase.org.jboss.as.test.integration.deployment.deploymentoverlay.DeploymentOverlayTestCase ? Deployment WarResourceListingTestCase.org.jboss.as.test.integration.deployment.resourcelisting.WarResourceListingTestCase ? Deployment WarClassLoadingTestCase.org.jboss.as.test.integration.deployment.classloading.war.WarClassLoadingTestCase ? Deployment WebModuleDeploymentTestCase.org.jboss.as.test.integration.web.annotationsmodule.WebModuleDeploymentTestCase ? Deployment CustomErrorsUnitTestCase.org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase ? Deployment FormAuthUnitTestCase.org.jboss.as.test.integration.web.formauth.FormAuthUnitTestCase ? Deployment UndertowHandlersConfigTestCase.org.jboss.as.test.integration.web.handlers.UndertowHandlersConfigTestCase ? Deployment RequestDumpingHandlerTestCase.org.jboss.as.test.integration.web.handlers.RequestDumpingHandlerTestCase ? Deployment ExternalTagLibTestCase.org.jboss.as.test.integration.web.jsp.taglib.external.ExternalTagLibTestCase ? Deployment JspMappingTestCase.org.jboss.as.test.integration.web.jsp.JspMappingTestCase ? Deployment JspSecurityManagerTestCase.org.jboss.as.test.integration.web.jsp.JspSecurityManagerTestCase ? Deployment DefaultServletMultipartConfigTestCase.org.jboss.as.test.integration.web.multipart.defaultservlet.DefaultServletMultipartConfigTestCase ? Deployment ReverseProxyTestCase.org.jboss.as.test.integration.web.reverseproxy.ReverseProxyTestCase ? Deployment ReverseProxyTestCase.tearDown:142 NullPointer RootContextWarUnitTestCase.org.jboss.as.test.integration.web.rootcontext.RootContextWarUnitTestCase ? Deployment RootContextEarUnitTestCase.org.jboss.as.test.integration.web.rootcontext.RootContextEarUnitTestCase ? Deployment WebSecurityBASICTestCase.org.jboss.as.test.integration.web.security.basic.WebSecurityBASICTestCase ? Deployment WebSecurityCERTTestCase.org.jboss.as.test.integration.web.security.cert.WebSecurityCERTTestCase ? Deployment WebSecurityExternalAuthTestCase.org.jboss.as.test.integration.web.security.external.WebSecurityExternalAuthTestCase ? Deployment WebSecurityJBossSimpleRoleMappingTestCase.org.jboss.as.test.integration.web.security.form.WebSecurityJBossSimpleRoleMappingTestCase ? Deployment WebSecurityFORMTestCase.org.jboss.as.test.integration.web.security.form.WebSecurityFORMTestCase ? Deployment WebSecurityProgrammaticLoginTestCase.org.jboss.as.test.integration.web.security.servlet3.WebSecurityProgrammaticLoginTestCase ? Deployment TransportGuaranteeTestCase.org.jboss.as.test.integration.web.security.tg.TransportGuaranteeTestCase ? Deployment ServletLifecycleMethodDescriptorTestCase.org.jboss.as.test.integration.web.servlet.lifecycle.ServletLifecycleMethodDescriptorTestCase ? Deployment EmptyCompEnvTestCase.org.jboss.as.test.integration.web.servlet.enc.empty.EmptyCompEnvTestCase ? Deployment ServletResourceOverlaysTestCase.org.jboss.as.test.integration.web.servlet.overlays.ServletResourceOverlaysTestCase ? Deployment SharedSessionTestCase.org.jboss.as.test.integration.web.sharedsession.SharedSessionTestCase ? Deployment ServletThreadPoolSelectionTestCase.org.jboss.as.test.integration.web.threads.ServletThreadPoolSelectionTestCase ? Deployment WebSocketTestCase.org.jboss.as.test.integration.web.websocket.WebSocketTestCase ? Deployment CookieUnitTestCase.org.jboss.as.test.integration.web.cookie.CookieUnitTestCase ? Deployment UndertowNonBlockingHandlerTestCase.org.jboss.as.test.integration.web.extension.UndertowNonBlockingHandlerTestCase ? Deployment DefaultConcurrencyServletTestCase.org.jboss.as.test.integration.ee.naming.defaultbindings.concurrency.DefaultConcurrencyServletTestCase ? Deployment DefaultContextServiceServletTestCase.org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase ? Deployment JspTagTestCase.org.jboss.as.test.integration.jsp.JspTagTestCase ? Deployment C... WarNotAsClientTest.org.jboss.as.test.smoke.web.WarNotAsClientTest ? Deployment WarTestCase.org.jboss.as.test.smoke.web.WarTestCase ? Deployment Cannot deploy... Tests run: 40, Failures: 0, Errors: 36, Skipped: 4 ... [INFO] WildFly: Servlet Distribution ...................... SUCCESS [ 10.220 s] [INFO] WildFly: Web Services Tests Integration Subsystem .. SUCCESS [ 8.569 s] [INFO] WildFly Test Suite: Shared ......................... SUCCESS [ 11.796 s] [INFO] WildFly Test Suite: Aggregator ..................... SUCCESS [02:18 min] [INFO] WildFly Test Suite: Integration .................... SUCCESS [ 7.957 s] [INFO] WildFly Test Suite: Integration - Web .............. FAILURE [01:07 min] [INFO] WildFly Test Suite: Integration - Smoke ............ SKIPPED The Caused by seems to be always the same: Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: JBOSS-LOCAL-USER: Server rejected authentication DIGEST-MD5: Server rejected authentication at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:393) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:198) at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:112) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) 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:89) at org.xnio.nio.WorkerThread.run(WorkerThread.java:545) at ...asynchronous invocation...(Unknown Source) at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:83) at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:114) at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257) at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71) at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:212) at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146) at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65) at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147) at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeAsync(AbstractModelControllerClient.java:111) at org.jboss.as.controller.client.helpers.standalone.impl.ModelControllerClientServerDeploymentManager.executeOperation(ModelControllerClientServerDeploymentManager.java:50) at org.jboss.as.controller.client.helpers.standalone.impl.AbstractServerDeploymentManager.execute(AbstractServerDeploymentManager.java:79) at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:54) at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) at org.junit.runners.Suite.runChild(Suite.java:127) at org.junit.runners.Suite.runChild(Suite.java:26) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.junit.runner.JUnitCore.run(JUnitCore.java:160) at org.junit.runner.JUnitCore.run(JUnitCore.java:138) at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113) at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85) at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54) at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) Connecting to the server via jboss-cli.sh to run a script fails also: Failed to connect to the controller: Unable to authenticate against controller at localhost:9990: Authentication failed: all available authentication mechanisms failed: DIGEST-MD5: Server rejected authentication Platform is Oracle Solaris SPARC 10. java version "1.8.0_60" Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) From tomaz.cerar at gmail.com Sun Aug 23 16:57:38 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Sun, 23 Aug 2015 22:57:38 +0200 Subject: [wildfly-dev] "WildFly Test Suite: Integration - Web" fails completely since today In-Reply-To: <55DA2304.2080601@osnanet.de> References: <55DA2304.2080601@osnanet.de> Message-ID: Well good thing is that it can reproduced on our CI with Sparc Solaris 11 as well. More in depth analysis what why this happened, will need to wait till tomorow. -- tomaz On Sun, Aug 23, 2015 at 9:46 PM, Frank Langelage wrote: > After checkout of current Wildfly 10 CR1 sources the build with smoke > tests fails. As of Friday everything was fine. > > Tests in error: > > DeploymentOverlayTestCase.org.jboss.as.test.integration.deployment.deploymentoverlay.DeploymentOverlayTestCase > ? Deployment > > WarResourceListingTestCase.org.jboss.as.test.integration.deployment.resourcelisting.WarResourceListingTestCase > ? Deployment > > WarClassLoadingTestCase.org.jboss.as.test.integration.deployment.classloading.war.WarClassLoadingTestCase > ? Deployment > > WebModuleDeploymentTestCase.org.jboss.as.test.integration.web.annotationsmodule.WebModuleDeploymentTestCase > ? Deployment > > CustomErrorsUnitTestCase.org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase > ? Deployment > > FormAuthUnitTestCase.org.jboss.as.test.integration.web.formauth.FormAuthUnitTestCase > ? Deployment > > UndertowHandlersConfigTestCase.org.jboss.as.test.integration.web.handlers.UndertowHandlersConfigTestCase > ? Deployment > > RequestDumpingHandlerTestCase.org.jboss.as.test.integration.web.handlers.RequestDumpingHandlerTestCase > ? Deployment > > ExternalTagLibTestCase.org.jboss.as.test.integration.web.jsp.taglib.external.ExternalTagLibTestCase > ? Deployment > JspMappingTestCase.org.jboss.as.test.integration.web.jsp.JspMappingTestCase > ? Deployment > > JspSecurityManagerTestCase.org.jboss.as.test.integration.web.jsp.JspSecurityManagerTestCase > ? Deployment > > DefaultServletMultipartConfigTestCase.org.jboss.as.test.integration.web.multipart.defaultservlet.DefaultServletMultipartConfigTestCase > ? Deployment > > ReverseProxyTestCase.org.jboss.as.test.integration.web.reverseproxy.ReverseProxyTestCase > ? Deployment > ReverseProxyTestCase.tearDown:142 NullPointer > > RootContextWarUnitTestCase.org.jboss.as.test.integration.web.rootcontext.RootContextWarUnitTestCase > ? Deployment > > RootContextEarUnitTestCase.org.jboss.as.test.integration.web.rootcontext.RootContextEarUnitTestCase > ? Deployment > > WebSecurityBASICTestCase.org.jboss.as.test.integration.web.security.basic.WebSecurityBASICTestCase > ? Deployment > > WebSecurityCERTTestCase.org.jboss.as.test.integration.web.security.cert.WebSecurityCERTTestCase > ? Deployment > > WebSecurityExternalAuthTestCase.org.jboss.as.test.integration.web.security.external.WebSecurityExternalAuthTestCase > ? Deployment > > WebSecurityJBossSimpleRoleMappingTestCase.org.jboss.as.test.integration.web.security.form.WebSecurityJBossSimpleRoleMappingTestCase > ? Deployment > > WebSecurityFORMTestCase.org.jboss.as.test.integration.web.security.form.WebSecurityFORMTestCase > ? Deployment > > WebSecurityProgrammaticLoginTestCase.org.jboss.as.test.integration.web.security.servlet3.WebSecurityProgrammaticLoginTestCase > ? Deployment > > TransportGuaranteeTestCase.org.jboss.as.test.integration.web.security.tg.TransportGuaranteeTestCase > ? Deployment > > ServletLifecycleMethodDescriptorTestCase.org.jboss.as.test.integration.web.servlet.lifecycle.ServletLifecycleMethodDescriptorTestCase > ? Deployment > > EmptyCompEnvTestCase.org.jboss.as.test.integration.web.servlet.enc.empty.EmptyCompEnvTestCase > ? Deployment > > ServletResourceOverlaysTestCase.org.jboss.as.test.integration.web.servlet.overlays.ServletResourceOverlaysTestCase > ? Deployment > > SharedSessionTestCase.org.jboss.as.test.integration.web.sharedsession.SharedSessionTestCase > ? Deployment > > ServletThreadPoolSelectionTestCase.org.jboss.as.test.integration.web.threads.ServletThreadPoolSelectionTestCase > ? Deployment > > WebSocketTestCase.org.jboss.as.test.integration.web.websocket.WebSocketTestCase > ? Deployment > > CookieUnitTestCase.org.jboss.as.test.integration.web.cookie.CookieUnitTestCase > ? Deployment > > UndertowNonBlockingHandlerTestCase.org.jboss.as.test.integration.web.extension.UndertowNonBlockingHandlerTestCase > ? Deployment > > DefaultConcurrencyServletTestCase.org.jboss.as.test.integration.ee.naming.defaultbindings.concurrency.DefaultConcurrencyServletTestCase > ? Deployment > > DefaultContextServiceServletTestCase.org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase > ? Deployment > JspTagTestCase.org.jboss.as.test.integration.jsp.JspTagTestCase ? > Deployment C... > WarNotAsClientTest.org.jboss.as.test.smoke.web.WarNotAsClientTest ? > Deployment > WarTestCase.org.jboss.as.test.smoke.web.WarTestCase ? Deployment > Cannot deploy... > > Tests run: 40, Failures: 0, Errors: 36, Skipped: 4 > > ... > [INFO] WildFly: Servlet Distribution ...................... SUCCESS [ > 10.220 s] > [INFO] WildFly: Web Services Tests Integration Subsystem .. SUCCESS [ > 8.569 s] > [INFO] WildFly Test Suite: Shared ......................... SUCCESS [ > 11.796 s] > [INFO] WildFly Test Suite: Aggregator ..................... SUCCESS > [02:18 min] > [INFO] WildFly Test Suite: Integration .................... SUCCESS [ > 7.957 s] > [INFO] WildFly Test Suite: Integration - Web .............. FAILURE > [01:07 min] > [INFO] WildFly Test Suite: Integration - Smoke ............ SKIPPED > > The Caused by seems to be always the same: > Caused by: javax.security.sasl.SaslException: Authentication failed: all > available authentication mechanisms failed: > JBOSS-LOCAL-USER: Server rejected authentication > DIGEST-MD5: Server rejected authentication > at > > org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114) > at > > org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:393) > at > > org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > > org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:198) > at > > org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:112) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > > org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) > 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:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:545) > at ...asynchronous invocation...(Unknown Source) > at > org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) > at > org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) > at > > org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:83) > at > > org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:114) > at > > org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257) > at > > org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71) > at > > org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:212) > at > > org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146) > at > > org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65) > at > > org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147) > at > > org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122) > at > > org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) > at > > org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) > at > > org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeAsync(AbstractModelControllerClient.java:111) > at > > org.jboss.as.controller.client.helpers.standalone.impl.ModelControllerClientServerDeploymentManager.executeOperation(ModelControllerClientServerDeploymentManager.java:50) > at > > org.jboss.as.controller.client.helpers.standalone.impl.AbstractServerDeploymentManager.execute(AbstractServerDeploymentManager.java:79) > at > > org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:54) > at > > org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at > > org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at > > org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at > > org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144) > at > > org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at > > org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at > > org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at > > org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > > org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at > > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at > > org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at > > org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at > > org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at > org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at > > org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at > > org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at > > org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at > > org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at > > org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source) > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > > org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at > > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at > org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at > > org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > > org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at > > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at > > org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at > > org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source) > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at > > org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) > at > org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) > at > org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at > org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at > org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runners.Suite.runChild(Suite.java:127) > at org.junit.runners.Suite.runChild(Suite.java:26) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > at > > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113) > at > > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85) > at > > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54) > at > > org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134) > at > > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) > at > > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > > Connecting to the server via jboss-cli.sh to run a script fails also: > Failed to connect to the controller: Unable to authenticate against > controller at localhost:9990: Authentication failed: all available > authentication mechanisms failed: > DIGEST-MD5: Server rejected authentication > > Platform is Oracle Solaris SPARC 10. > > java version "1.8.0_60" > Java(TM) SE Runtime Environment (build 1.8.0_60-b27) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) > > _______________________________________________ > 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/20150823/92a2454a/attachment-0001.html From frank.langelage at osnanet.de Sun Aug 23 18:11:39 2015 From: frank.langelage at osnanet.de (Frank Langelage) Date: Mon, 24 Aug 2015 00:11:39 +0200 Subject: [wildfly-dev] "WildFly Test Suite: Integration - Web" fails completely since today In-Reply-To: References: <55DA2304.2080601@osnanet.de> Message-ID: <55DA451B.7030207@osnanet.de> A build on Windows 7 using Java 1.8.0_60 shows similar problems for me. On 23.08.15 22:57, Toma? Cerar wrote: > > Well good thing is that it can reproduced on our CI with Sparc Solaris > 11 as well. > > More in depth analysis what why this happened, will need to wait till > tomorow. > > -- > tomaz > > On Sun, Aug 23, 2015 at 9:46 PM, Frank Langelage > > wrote: > > After checkout of current Wildfly 10 CR1 sources the build with smoke > tests fails. As of Friday everything was fine. > > Tests in error: > DeploymentOverlayTestCase.org.jboss.as.test.integration.deployment.deploymentoverlay.DeploymentOverlayTestCase > ? Deployment > WarResourceListingTestCase.org.jboss.as.test.integration.deployment.resourcelisting.WarResourceListingTestCase > ? Deployment > WarClassLoadingTestCase.org.jboss.as.test.integration.deployment.classloading.war.WarClassLoadingTestCase > ? Deployment > WebModuleDeploymentTestCase.org.jboss.as.test.integration.web.annotationsmodule.WebModuleDeploymentTestCase > ? Deployment > CustomErrorsUnitTestCase.org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase > ? Deployment > FormAuthUnitTestCase.org.jboss.as.test.integration.web.formauth.FormAuthUnitTestCase > ? Deployment > UndertowHandlersConfigTestCase.org.jboss.as.test.integration.web.handlers.UndertowHandlersConfigTestCase > ? Deployment > RequestDumpingHandlerTestCase.org.jboss.as.test.integration.web.handlers.RequestDumpingHandlerTestCase > ? Deployment > ExternalTagLibTestCase.org.jboss.as.test.integration.web.jsp.taglib.external.ExternalTagLibTestCase > ? Deployment > JspMappingTestCase.org.jboss.as.test.integration.web.jsp.JspMappingTestCase > ? Deployment > JspSecurityManagerTestCase.org.jboss.as.test.integration.web.jsp.JspSecurityManagerTestCase > ? Deployment > DefaultServletMultipartConfigTestCase.org.jboss.as.test.integration.web.multipart.defaultservlet.DefaultServletMultipartConfigTestCase > ? Deployment > ReverseProxyTestCase.org.jboss.as.test.integration.web.reverseproxy.ReverseProxyTestCase > ? Deployment > ReverseProxyTestCase.tearDown:142 NullPointer > RootContextWarUnitTestCase.org.jboss.as.test.integration.web.rootcontext.RootContextWarUnitTestCase > ? Deployment > RootContextEarUnitTestCase.org.jboss.as.test.integration.web.rootcontext.RootContextEarUnitTestCase > ? Deployment > WebSecurityBASICTestCase.org.jboss.as.test.integration.web.security.basic.WebSecurityBASICTestCase > ? Deployment > WebSecurityCERTTestCase.org.jboss.as.test.integration.web.security.cert.WebSecurityCERTTestCase > ? Deployment > WebSecurityExternalAuthTestCase.org.jboss.as.test.integration.web.security.external.WebSecurityExternalAuthTestCase > ? Deployment > WebSecurityJBossSimpleRoleMappingTestCase.org.jboss.as.test.integration.web.security.form.WebSecurityJBossSimpleRoleMappingTestCase > ? Deployment > WebSecurityFORMTestCase.org.jboss.as.test.integration.web.security.form.WebSecurityFORMTestCase > ? Deployment > WebSecurityProgrammaticLoginTestCase.org.jboss.as.test.integration.web.security.servlet3.WebSecurityProgrammaticLoginTestCase > ? Deployment > TransportGuaranteeTestCase.org.jboss.as.test.integration.web.security.tg.TransportGuaranteeTestCase > ? Deployment > ServletLifecycleMethodDescriptorTestCase.org.jboss.as.test.integration.web.servlet.lifecycle.ServletLifecycleMethodDescriptorTestCase > ? Deployment > EmptyCompEnvTestCase.org.jboss.as.test.integration.web.servlet.enc.empty.EmptyCompEnvTestCase > ? Deployment > ServletResourceOverlaysTestCase.org.jboss.as.test.integration.web.servlet.overlays.ServletResourceOverlaysTestCase > ? Deployment > SharedSessionTestCase.org.jboss.as.test.integration.web.sharedsession.SharedSessionTestCase > ? Deployment > ServletThreadPoolSelectionTestCase.org.jboss.as.test.integration.web.threads.ServletThreadPoolSelectionTestCase > ? Deployment > WebSocketTestCase.org.jboss.as.test.integration.web.websocket.WebSocketTestCase > ? Deployment > CookieUnitTestCase.org.jboss.as.test.integration.web.cookie.CookieUnitTestCase > ? Deployment > UndertowNonBlockingHandlerTestCase.org.jboss.as.test.integration.web.extension.UndertowNonBlockingHandlerTestCase > ? Deployment > DefaultConcurrencyServletTestCase.org.jboss.as.test.integration.ee.naming.defaultbindings.concurrency.DefaultConcurrencyServletTestCase > ? Deployment > DefaultContextServiceServletTestCase.org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase > ? Deployment > JspTagTestCase.org.jboss.as.test.integration.jsp.JspTagTestCase ? > Deployment C... > WarNotAsClientTest.org.jboss.as.test.smoke.web.WarNotAsClientTest ? > Deployment > WarTestCase.org.jboss.as.test.smoke.web.WarTestCase ? Deployment > Cannot deploy... > > Tests run: 40, Failures: 0, Errors: 36, Skipped: 4 > > ... > [INFO] WildFly: Servlet Distribution ...................... SUCCESS [ > 10.220 s] > [INFO] WildFly: Web Services Tests Integration Subsystem .. SUCCESS [ > 8.569 s] > [INFO] WildFly Test Suite: Shared ......................... SUCCESS [ > 11.796 s] > [INFO] WildFly Test Suite: Aggregator ..................... SUCCESS > [02:18 min] > [INFO] WildFly Test Suite: Integration .................... SUCCESS [ > 7.957 s] > [INFO] WildFly Test Suite: Integration - Web .............. FAILURE > [01:07 min] > [INFO] WildFly Test Suite: Integration - Smoke ............ SKIPPED > > The Caused by seems to be always the same: > Caused by: javax.security.sasl.SaslException: Authentication > failed: all > available authentication mechanisms failed: > JBOSS-LOCAL-USER: Server rejected authentication > DIGEST-MD5: Server rejected authentication > at > org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114) > at > org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:393) > at > org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:198) > at > org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:112) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) > 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:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:545) > at ...asynchronous invocation...(Unknown Source) > at > org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) > at > org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) > at > org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) > at > org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) > at > org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:83) > at > org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:114) > at > org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257) > at > org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71) > at > org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:212) > at > org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146) > at > org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65) > at > org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147) > at > org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) > at > org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeAsync(AbstractModelControllerClient.java:111) > at > org.jboss.as.controller.client.helpers.standalone.impl.ModelControllerClientServerDeploymentManager.executeOperation(ModelControllerClientServerDeploymentManager.java:50) > at > org.jboss.as.controller.client.helpers.standalone.impl.AbstractServerDeploymentManager.execute(AbstractServerDeploymentManager.java:79) > at > org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:54) > at > org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) > at > org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) > at > org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) > at > org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144) > at > org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) > at > org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) > at > org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) > at > org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) > at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown > Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at > org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown > Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at > org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) > at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown > Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at > org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) > at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown > Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at > org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at > org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) > at > org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) > at > org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) > at > org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) > at > org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) > at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown > Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at > org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at > org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) > at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown > Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at > org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown > Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at > org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) > at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown > Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) > at > org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) > at > org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) > at > org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) > at > org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) > at > org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) > at > org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) > at > org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at > org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) > at org.junit.runners.Suite.runChild(Suite.java:127) > at org.junit.runners.Suite.runChild(Suite.java:26) > at > org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at > org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at > org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.junit.runner.JUnitCore.run(JUnitCore.java:160) > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54) > at > org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134) > at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > > Connecting to the server via jboss-cli.sh to run a script fails also: > Failed to connect to the controller: Unable to authenticate against > controller at localhost:9990: Authentication failed: all available > authentication mechanisms failed: > DIGEST-MD5: Server rejected authentication > > Platform is Oracle Solaris SPARC 10. > > java version "1.8.0_60" > Java(TM) SE Runtime Environment (build 1.8.0_60-b27) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) > > _______________________________________________ > 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/20150824/8e865b57/attachment-0001.html From kabir.khan at jboss.com Mon Aug 24 09:38:20 2015 From: kabir.khan at jboss.com (Kabir Khan) Date: Mon, 24 Aug 2015 15:38:20 +0200 Subject: [wildfly-dev] Metrics & runtime attribute registration In-Reply-To: <55ACF882.9040907@redhat.com> References: <55A6A5D2.8020506@redhat.com> <55ACF882.9040907@redhat.com> Message-ID: I am looking at https://issues.jboss.org/browse/WFCORE-831. Basically what is new is registering the same ?stuff? for an admin-only server, as for a normal server. Does this only apply to attributes? Having a glance of the usage of EC.isRuntimeOnlyRegistrationValid(), in addition to toggling registration of attributes we currently use is to toggle: a) Register runtime resources in the main subsystem model model (probably some examples in messaging) b) Register deployment resources (e.g. logging and datasources) c) Register runtime operations (e.g. jdr report, Ds flush) I don't think having b) and c) makes sense if it is an admin-only server, but perhaps a) does? Still, where would the data for a) come from? > On 20 Jul 2015, at 15:32, Brian Stansberry wrote: > > Silence is assent. ;) So I've opened > https://issues.jboss.org/browse/WFCORE-831. > > On 7/15/15 1:26 PM, Brian Stansberry wrote: >> Based on the discussion in this thread and some related chats in >> hipchat, I propose the requirements below for this general topic, and >> very much welcome comments. >> >> Note that this thread is about metrics, but handling of non-metric >> runtime-only attributes and operations all have the same concerns. >> >> I've placed an * next to requirements that involve some code change in >> the WildFly Core kernel. If we can reach a consensus around these >> requirements, that consensus can become a JIRA to implement the * items. >> >> I. If an Extension's initialize method is executing in a process type >> where the extension CAN install runtime services, the extension MUST >> register all metrics, other runtime-only attributes, and runtime-only >> operations, regardless of whether the process is running in --admin-only >> mode. >> >> II. If an Extension's initialize method is executing in a process type >> where the extension CANNOT install runtime services, the extension MUST >> NOT register any metrics, other runtime-only attributes, or runtime-only >> operations.[1] For example, most extensions will not register these when >> executing on a HostController. >> >> III.* The ExtensionContext.isRuntimeOnlyRegistrationValid() MUST return >> the proper value to tell the extension which of conditions I and II apply. >> >> IV.* The AttributeDefinition class MUST expose a 'public ModelNode >> getUndefinedMetricValue()' method and the builders for it MUST expose a >> 'public void setUndefinedMetricValue(ModelNode value)' method. (See VI.A >> below for the purpose of this.) >> >> A.* If assertions are enabled and an AttributeDefinition that is passed >> to ManagementResourceRegistration registerReadOnlyAttribute or >> registerReadWriteAttribute returns a defined ModelNode from >> getUndefinedMetricValue(), an AssertionError MUST be thrown. Non-metrics >> cannot provide undefined metric values. >> >> B.* If assertions are enabled and an AttributeDefinition that is passed >> to ManagementResourceRegistration registerMetric returns a defined >> ModelNode from getDefaultValue(), an AssertionError MUST be thrown. >> Metrics cannot provide default values. >> >> C.* If assertions are enabled and an AttributeDefinition that is passed >> to ManagementResourceRegistration registerMetric returns a defined >> ModelNode from getUndefinedMetricValue() and also returns 'true' from >> isAllowNull(), an AssertionError MUST be thrown. This is an inconsistent >> setting, as the undefined metric value will ensure the client never sees >> an undefined result. >> >> V. The read-attribute handler for a metric or runtime-only attribute >> MUST set a result value consistent with the attribute description >> regardless of whether the expected runtime services are disabled due to >> running in --admin-only or some other configuration option such as a >> 'statistics-enabled' attribute being set to 'false'. Specifically, if >> the handler might not set a defined value in that situation, the >> isAllowNull() method from the attribute's AttributeDefinition MUST >> return 'true'. >> >> VI. The read-attribute handler for metrics that have a logical defined >> value even if runtime services are not present SHOULD set that value as >> the result when runtime services are not present. For example, for many >> 'counter' metrics a value of 0 is a logical defined value. >> >> A. The read-attribute handler for such a metric MAY choose to not set a >> result value itself when there are no runtime services, and instead >> delegate to the kernel to have the kernel set the result. To configure >> such a delegation, the AttributeDefinition for the metric must return a >> defined value from its getUndefinedMetricValue() method. (See IV.) >> >> B.* The kernel's handler for read-attribute MUST check if the registered >> handler for the attribute has not set a defined result. If it has not, >> and the attribute is a metric, and its definition's >> getUndefinedMetricValue() method returns a defined value, the kernel >> handler must set that value as the result. This behavior MUST occur >> regardless of the value of any 'include-defaults' parameter passed to >> the hander. The 'include-defaults' parameter is unrelated to metrics. >> >> VII. The read-attribute handler for metrics that do not have a logical >> defined value if runtime services are not present SHOULD return an >> undefined result and SHOULD NOT return an arbitrary meaningless value >> such as -1 or Integer.MAX_VALUE. This is not a MUST/MUST NOT requirement >> because it is understood that backwards compatibility requirements may >> prevent changes to some attributes, and also that some integrated >> libraries may return such values without the subsystem handler's being >> aware of that. >> >> VIII. The read-attribute handler for a custom runtime-only operation >> MUST set a result value consistent with the operation description >> regardless of whether the expected runtime services are disabled due to >> running in --admin-only or some other configuration option. >> Specifically, if the handler might not set a defined value in that >> situation, the isReplyAllowNull() method from the attribute's >> OperationDefinition MUST return 'true'. >> >> A. However, it is permissible for a custom runtime-only operation >> handler to throw an OperationFailedException in this situation. The >> 'runtime-only'=>true entry in the operation's descriptive metadata >> provides an indication to callers that this is a possible result. >> >> I think that's about it. ;) >> >> [1] At some point in the future the restriction on runtime-only >> operations may be lifted, in order to support executing the operation on >> all servers in a domain. >> >> On 7/13/15 4:26 PM, Toma? Cerar wrote: >>> Hey guys, >>> >>> We had interesting discussion with Brian on >>> https://github.com/wildfly/wildfly-core/pull/848#issuecomment-119778986 >>> about how we register runtime/metric attribute on resources. >>> >>> There are many cases where subsystems only register attributes / >>> resources only when server is booting into normal mode. >>> but if it server is booted only to "admin mode" all that runtime/metrics >>> attributes are not registered and as such not seen in the model. >>> >>> Registering runtime attributes only in normal mode can cause that >>> results of :read-resource-description/read-resource >>> wouldn't return attributes that are on resources if server is started in >>> admin mode or even CLI standalone. >>> Our metadata already provides information if attributes is >>> runtime/metric/configuration. >>> >>> This can cause problems for tooling that relies on output of those two >>> operations. >>> >>> Looking at current state of the code, we do use both ways of registering >>> attributes either conditionally or always. >>> This probably originates from times where there was no good api/way to >>> mark attribute/resource as runtime. >>> >>> I am personally am in favor of always registering runtime attributes as >>> this makes sure that user isn't surprised by some extra/missing >>> attributes based on fact how it is starting the server. >>> >>> >>> What do you guys think? Should we always register it or have it >>> conditionally? >>> >>> -- >>> tomaz >>> >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >> >> > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Mon Aug 24 09:56:27 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 24 Aug 2015 08:56:27 -0500 Subject: [wildfly-dev] Metrics & runtime attribute registration In-Reply-To: References: <55A6A5D2.8020506@redhat.com> <55ACF882.9040907@redhat.com> Message-ID: <55DB228B.1060908@redhat.com> The basic thrust of this thread was that the *API* should not be changing based on things like --admin-only or statistics-enabled=false. The results obtained by invoking ops can change, though, so long as those results are consistent with the published metadata. So, I don't see a problem with c). VII.A. in the WFCORE-831 description covers (admittedly in a not-so-elegant way) how the results obtained can change: "However, it is permissible for a custom runtime-only operation handler to throw an OperationFailedException in this situation. The 'runtime-only'=>true entry in the operation's descriptive metadata provides an indication to callers that this is a possible result." Where this starts to break down is if the API promises that a particular resource will exist, and it just can't. Carrying the WFCORE-831 semantics for metrics all the way forward to creating fictitious resources is too far. If a child runtime-only resource is registered under foo=* that's not such a problem as there's no promise that any particular value of "*" will exist. But /deployment=x.war/subsystem=logging is more of a problem. Extending the VIII.A type thing to a child resource (i.e so throwing NoSuchResourceException is ok, because the resource is 'runtime-only' sounds bad. People invoke custom ops like 'flush-ds' intentionally. But trying to walk a resource tree is something much more likely to be done automatically by a tool. How forgiving is the read-resource handler? IIRC there's logic in there to ignore some sorts of runtime-only failures, to avoid their causing recursive reads to fail. On 8/24/15 8:38 AM, Kabir Khan wrote: > I am looking at https://issues.jboss.org/browse/WFCORE-831. Basically what is new is registering the same ?stuff? for an admin-only server, as for a normal server. Does this only apply to attributes? > Having a glance of the usage of EC.isRuntimeOnlyRegistrationValid(), in addition to toggling registration of attributes we currently use is to toggle: > > a) Register runtime resources in the main subsystem model model (probably some examples in messaging) > b) Register deployment resources (e.g. logging and datasources) > c) Register runtime operations (e.g. jdr report, Ds flush) > > I don't think having b) and c) makes sense if it is an admin-only server, but perhaps a) does? Still, where would the data for a) come from? > > >> On 20 Jul 2015, at 15:32, Brian Stansberry wrote: >> >> Silence is assent. ;) So I've opened >> https://issues.jboss.org/browse/WFCORE-831. >> >> On 7/15/15 1:26 PM, Brian Stansberry wrote: >>> Based on the discussion in this thread and some related chats in >>> hipchat, I propose the requirements below for this general topic, and >>> very much welcome comments. >>> >>> Note that this thread is about metrics, but handling of non-metric >>> runtime-only attributes and operations all have the same concerns. >>> >>> I've placed an * next to requirements that involve some code change in >>> the WildFly Core kernel. If we can reach a consensus around these >>> requirements, that consensus can become a JIRA to implement the * items. >>> >>> I. If an Extension's initialize method is executing in a process type >>> where the extension CAN install runtime services, the extension MUST >>> register all metrics, other runtime-only attributes, and runtime-only >>> operations, regardless of whether the process is running in --admin-only >>> mode. >>> >>> II. If an Extension's initialize method is executing in a process type >>> where the extension CANNOT install runtime services, the extension MUST >>> NOT register any metrics, other runtime-only attributes, or runtime-only >>> operations.[1] For example, most extensions will not register these when >>> executing on a HostController. >>> >>> III.* The ExtensionContext.isRuntimeOnlyRegistrationValid() MUST return >>> the proper value to tell the extension which of conditions I and II apply. >>> >>> IV.* The AttributeDefinition class MUST expose a 'public ModelNode >>> getUndefinedMetricValue()' method and the builders for it MUST expose a >>> 'public void setUndefinedMetricValue(ModelNode value)' method. (See VI.A >>> below for the purpose of this.) >>> >>> A.* If assertions are enabled and an AttributeDefinition that is passed >>> to ManagementResourceRegistration registerReadOnlyAttribute or >>> registerReadWriteAttribute returns a defined ModelNode from >>> getUndefinedMetricValue(), an AssertionError MUST be thrown. Non-metrics >>> cannot provide undefined metric values. >>> >>> B.* If assertions are enabled and an AttributeDefinition that is passed >>> to ManagementResourceRegistration registerMetric returns a defined >>> ModelNode from getDefaultValue(), an AssertionError MUST be thrown. >>> Metrics cannot provide default values. >>> >>> C.* If assertions are enabled and an AttributeDefinition that is passed >>> to ManagementResourceRegistration registerMetric returns a defined >>> ModelNode from getUndefinedMetricValue() and also returns 'true' from >>> isAllowNull(), an AssertionError MUST be thrown. This is an inconsistent >>> setting, as the undefined metric value will ensure the client never sees >>> an undefined result. >>> >>> V. The read-attribute handler for a metric or runtime-only attribute >>> MUST set a result value consistent with the attribute description >>> regardless of whether the expected runtime services are disabled due to >>> running in --admin-only or some other configuration option such as a >>> 'statistics-enabled' attribute being set to 'false'. Specifically, if >>> the handler might not set a defined value in that situation, the >>> isAllowNull() method from the attribute's AttributeDefinition MUST >>> return 'true'. >>> >>> VI. The read-attribute handler for metrics that have a logical defined >>> value even if runtime services are not present SHOULD set that value as >>> the result when runtime services are not present. For example, for many >>> 'counter' metrics a value of 0 is a logical defined value. >>> >>> A. The read-attribute handler for such a metric MAY choose to not set a >>> result value itself when there are no runtime services, and instead >>> delegate to the kernel to have the kernel set the result. To configure >>> such a delegation, the AttributeDefinition for the metric must return a >>> defined value from its getUndefinedMetricValue() method. (See IV.) >>> >>> B.* The kernel's handler for read-attribute MUST check if the registered >>> handler for the attribute has not set a defined result. If it has not, >>> and the attribute is a metric, and its definition's >>> getUndefinedMetricValue() method returns a defined value, the kernel >>> handler must set that value as the result. This behavior MUST occur >>> regardless of the value of any 'include-defaults' parameter passed to >>> the hander. The 'include-defaults' parameter is unrelated to metrics. >>> >>> VII. The read-attribute handler for metrics that do not have a logical >>> defined value if runtime services are not present SHOULD return an >>> undefined result and SHOULD NOT return an arbitrary meaningless value >>> such as -1 or Integer.MAX_VALUE. This is not a MUST/MUST NOT requirement >>> because it is understood that backwards compatibility requirements may >>> prevent changes to some attributes, and also that some integrated >>> libraries may return such values without the subsystem handler's being >>> aware of that. >>> >>> VIII. The read-attribute handler for a custom runtime-only operation >>> MUST set a result value consistent with the operation description >>> regardless of whether the expected runtime services are disabled due to >>> running in --admin-only or some other configuration option. >>> Specifically, if the handler might not set a defined value in that >>> situation, the isReplyAllowNull() method from the attribute's >>> OperationDefinition MUST return 'true'. >>> >>> A. However, it is permissible for a custom runtime-only operation >>> handler to throw an OperationFailedException in this situation. The >>> 'runtime-only'=>true entry in the operation's descriptive metadata >>> provides an indication to callers that this is a possible result. >>> >>> I think that's about it. ;) >>> >>> [1] At some point in the future the restriction on runtime-only >>> operations may be lifted, in order to support executing the operation on >>> all servers in a domain. >>> >>> On 7/13/15 4:26 PM, Toma? Cerar wrote: >>>> Hey guys, >>>> >>>> We had interesting discussion with Brian on >>>> https://github.com/wildfly/wildfly-core/pull/848#issuecomment-119778986 >>>> about how we register runtime/metric attribute on resources. >>>> >>>> There are many cases where subsystems only register attributes / >>>> resources only when server is booting into normal mode. >>>> but if it server is booted only to "admin mode" all that runtime/metrics >>>> attributes are not registered and as such not seen in the model. >>>> >>>> Registering runtime attributes only in normal mode can cause that >>>> results of :read-resource-description/read-resource >>>> wouldn't return attributes that are on resources if server is started in >>>> admin mode or even CLI standalone. >>>> Our metadata already provides information if attributes is >>>> runtime/metric/configuration. >>>> >>>> This can cause problems for tooling that relies on output of those two >>>> operations. >>>> >>>> Looking at current state of the code, we do use both ways of registering >>>> attributes either conditionally or always. >>>> This probably originates from times where there was no good api/way to >>>> mark attribute/resource as runtime. >>>> >>>> I am personally am in favor of always registering runtime attributes as >>>> this makes sure that user isn't surprised by some extra/missing >>>> attributes based on fact how it is starting the server. >>>> >>>> >>>> What do you guys think? Should we always register it or have it >>>> conditionally? >>>> >>>> -- >>>> tomaz >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jason.greene at redhat.com Mon Aug 24 18:16:38 2015 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 24 Aug 2015 17:16:38 -0500 Subject: [wildfly-dev] clarification on why Wildfly versions are increasing so quickly In-Reply-To: References: Message-ID: The versioning really just reflects our desire to be a bit more incremental with feature delivery, and to have a regular release schedule that encourages participation and involvement. Overall I think we are still a very mature and conservative project. As anyone who has ever submitted a contribution will tell you, we have numerous checks and reviews throughout the whole process. As to the actual interval, we aim to have Final releases around 6-9 months apart, although that can fluctuate depending on the feature set, and if we are absorbing say a new Java EE release. > On Aug 19, 2015, at 8:38 AM, Karl Pietrzak wrote: > > Hi everyone! > > First off, kudos to everyone for a great product! > > Secondly, I'm wondering if someone could explain to me the significance of the quick succession of Wildfly version upgrades: from 8 -> 9 -> 10 (soon). > > It seemed like we were on JBoss 7.x for a long time, and now the top link at http://wildfly.org/downloads/ is actually the Wildfly 10.x beta. > > Does this represent: > 1. a sudden increase in contributions and feature work? > 2. shift in marketing (i.e., no underlying tech changes) > 3. something else > > Our concern is that this represents some instability / internal dynamics / change in policy that would encourage us to visit other app servers. > > Thank you! > > -- > Karl > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150824/4f021844/attachment-0001.html From jmesnil at redhat.com Tue Aug 25 05:00:46 2015 From: jmesnil at redhat.com (Jeff Mesnil) Date: Tue, 25 Aug 2015 11:00:46 +0200 Subject: [wildfly-dev] Migration management operation - open questions In-Reply-To: References: <1842533956.9474631.1438928780011.JavaMail.zimbra@redhat.com> <55C8BE51.4030203@redhat.com> <3DB85C0C-B21E-413B-B287-B94A3DC081DC@redhat.com> Message-ID: <6F6D6D9F-F515-4C49-A34F-75580E0459B5@redhat.com> > On 20 Aug 2015, at 20:06, Jason Greene wrote: >> >> I have a such an use case where I can?t migrate feature from the legacy messaging subsystem to the new messaging-activemq subsystem. >> >> In the legacy subsystem, HA policy is driven by 2 attributes on the hornetq-server resource (shared-store and backup which both are BOOLEAN attribute that allow expressions). >> In the new messaging-activemq subsystem, HA policy is configured by different child for the ha-policy resource (shared-store-slave, shared-store-master, replication-master, replication-slave and others). >> >> During the migration, I can not just read the values of the share-store and backup attributes to determine the type of ha-policy to use in the new subsystems. If they use expressions, their values are determined by the system properties set for each server. > > That?s detectable though right? If there is no expression is it mappable? Yes it is. I ended up doing that in my PR[1]: if there is no expressions involved, I can unambiguously map the legacy HA configuration to a new one. Otherwise, I discard the HA configuration and warns the user that its new messaging-activemq subsystem will not have HA configured properly. jeff [1] https://github.com/wildfly/wildfly/pull/7977 -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From dennis.brouwer at kizitos.com Tue Aug 25 10:31:48 2015 From: dennis.brouwer at kizitos.com (Dennis Brouwer) Date: Tue, 25 Aug 2015 16:31:48 +0200 Subject: [wildfly-dev] Widlfly 9.0.1.Final - subsystem expression evaluation not entirely water proof Message-ID: Dear reader, We recently moved to Wildfly 9.0.1.Final (from 8.2.0) for testing and stumbled upon a bug regarding expression evaluation in the standalone*.xml. Let me give an example for the following subsystem: ... Since we have several deployment stages on one physical server we need to separate the clusters by using a distinct name for each one of the stages deployed. Hence we introduced a startup property to be substituted in the standalone*.xml configuration like following snippet clarifies: ... Using this approach however fails to start the container because the channels default attribute is properly evaluated to "ee" (accoding to specs). However the channel name attribute is not evaluated at all and is registered as "${custom_clustername:ee}" (without the quotes). I took the liberty to dig in the class: org.jboss.as.clustering.jgroups.subsystem.JGroupsSubsystemXMLReader and manually do the expression evaluation for the channel name. At first glance this seems to work however the container rewrites the standalone*.xml file at a certain moment resulting in this snippet: ... Which on subsequent container starts and when using the -Dcustom_clustername=whee startup property causes a problem because the channels default is evaluated to "whee" and the channel name remains "ee". So my questions are: 1] How to solve this issue in a correct way? 2] Can somebody provide another mechanism to configure a non default channel name on startup? -- Best regards, *Dennis Brouwer* Extraordinary Goalkeeper ZEEF - Kizitos B.V. Amstelboulevard 184 1096 HM Amsterdam www.ZEEF.com US: +1 (415) 992-9409 NL: +31 (085) 888-3186 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150825/f5b4092e/attachment.html From brian.stansberry at redhat.com Tue Aug 25 11:04:25 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 25 Aug 2015 10:04:25 -0500 Subject: [wildfly-dev] Widlfly 9.0.1.Final - subsystem expression evaluation not entirely water proof In-Reply-To: References: Message-ID: <55DC83F9.9050100@redhat.com> This attribute does not support use of expressions, so any data you provide is evaluated simply as a string. It doesn't support expressions because it is what we call a "model reference" attribute. It's value refers to another element in the configuration model. We do not allow expressions in those attributes because it is not possible to have all the necessary data to resolve the expression at the points in time when the correctness of the model must be validated. On 8/25/15 9:31 AM, Dennis Brouwer wrote: > Dear reader, > > We recently moved to Wildfly 9.0.1.Final (from 8.2.0) for testing and > stumbled upon a bug regarding expression evaluation in the standalone*.xml. > > Let me give an example for the following subsystem: > > > > > > ... > > > Since we have several deployment stages on one physical server we need > to separate the clusters by using a distinct name for each one of the > stages deployed. Hence we introduced a startup property to be > substituted in the standalone*.xml configuration like following snippet > clarifies: > > > > > > ... > > > Using this approach however fails to start the container because the > channels default attribute is properly evaluated to "ee" (accoding to > specs). However the channel name attribute is not evaluated at all and > is registered as "${custom_clustername:ee}" (without the quotes). > > I took the liberty to dig in the class: > org.jboss.as.clustering.jgroups.subsystem.JGroupsSubsystemXMLReader and > manually do the expression evaluation for the channel name. At first > glance this seems to work however the container rewrites the > standalone*.xml file at a certain moment resulting in this snippet: > > > > > > ... > > > Which on subsequent container starts and when using the > -Dcustom_clustername=whee startup property causes a problem because the > channels default is evaluated to "whee" and the channel name remains "ee". > > > So my questions are: > > 1] How to solve this issue in a correct way? > 2] Can somebody provide another mechanism to configure a non default > channel name on startup? > > > -- > Best regards, > > *Dennis Brouwer* > Extraordinary Goalkeeper > > > > > ZEEF - Kizitos B.V. > Amstelboulevard 184 > 1096 HM Amsterdam > www.ZEEF.com > US: +1 (415) 992-9409 > NL: +31 (085) 888-3186 > > > _______________________________________________ > 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 dennis.brouwer at kizitos.com Tue Aug 25 11:54:40 2015 From: dennis.brouwer at kizitos.com (Dennis Brouwer) Date: Tue, 25 Aug 2015 17:54:40 +0200 Subject: [wildfly-dev] Widlfly 9.0.1.Final - subsystem expression evaluation not entirely water proof In-Reply-To: <55DC83F9.9050100@redhat.com> References: <55DC83F9.9050100@redhat.com> Message-ID: Thanks Brain for answering this however I am still a bit puzzled, Let me explain: On Tue, Aug 25, 2015 at 5:04 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > This attribute does not support use of expressions, so any data you > provide is evaluated simply as a string. > > "This attribute" most likely refers to the name attribute in if I interpret your sentence correctly. If so, why not create an extra attribute CLUSTER_NAME next to the existing STACK and MODULE attributes and use the CLUSTER_NAME to create the JChannel. Using the current configuration model all containers start up with default cluster name "ee" unless the standalone*.xml file is edited beforehand. This is practically undoable because the cluster name defaults to the name of the channel used and I didn't find a way to overrule this (I might have overlooked something of course). The only way to make distinct clusters is to add a bunch of pre-defined channel definitions and change the channels default. example: * ** ** * * * * ** ** ... *** And then select one of the names using the -Dcustom_clustername=[|whee|foo] startup property. However the desired behavior is to be flexible and provide a random name at startup time. It doesn't support expressions because it is what we call a "model > reference" attribute. It's value refers to another element in the > configuration model. We do not allow expressions in those attributes > because it is not possible to have all the necessary data to resolve the > expression at the points in time when the correctness of the model must > be validated. > > On 8/25/15 9:31 AM, Dennis Brouwer wrote: > > Dear reader, > > > > We recently moved to Wildfly 9.0.1.Final (from 8.2.0) for testing and > > stumbled upon a bug regarding expression evaluation in the > standalone*.xml. > > > > Let me give an example for the following subsystem: > > > > > > > > > > > > ... > > > > > > Since we have several deployment stages on one physical server we need > > to separate the clusters by using a distinct name for each one of the > > stages deployed. Hence we introduced a startup property to be > > substituted in the standalone*.xml configuration like following snippet > > clarifies: > > > > > > > > > > > > ... > > > > > > Using this approach however fails to start the container because the > > channels default attribute is properly evaluated to "ee" (accoding to > > specs). However the channel name attribute is not evaluated at all and > > is registered as "${custom_clustername:ee}" (without the quotes). > > > > I took the liberty to dig in the class: > > org.jboss.as.clustering.jgroups.subsystem.JGroupsSubsystemXMLReader and > > manually do the expression evaluation for the channel name. At first > > glance this seems to work however the container rewrites the > > standalone*.xml file at a certain moment resulting in this snippet: > > > > > > > > > > > > ... > > > > > > Which on subsequent container starts and when using the > > -Dcustom_clustername=whee startup property causes a problem because the > > channels default is evaluated to "whee" and the channel name remains > "ee". > > > > > > So my questions are: > > > > 1] How to solve this issue in a correct way? > > 2] Can somebody provide another mechanism to configure a non default > > channel name on startup? > > > > > > -- > > Best regards, > > > > *Dennis Brouwer* > > Extraordinary Goalkeeper > > > > > > > > > > ZEEF - Kizitos B.V. > > Amstelboulevard 184 > > 1096 HM Amsterdam > > www.ZEEF.com > > US: +1 (415) 992-9409 > > NL: +31 (085) 888-3186 > > > > > > _______________________________________________ > > 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 > -- Best regards, *Dennis Brouwer* Extraordinary Goalkeeper ZEEF - Kizitos B.V. Amstelboulevard 184 1096 HM Amsterdam www.ZEEF.com US: +1 (415) 992-9409 NL: +31 (085) 888-3186 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150825/7795ba8d/attachment-0001.html From brian.stansberry at redhat.com Tue Aug 25 12:34:11 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 25 Aug 2015 11:34:11 -0500 Subject: [wildfly-dev] Widlfly 9.0.1.Final - subsystem expression evaluation not entirely water proof In-Reply-To: References: <55DC83F9.9050100@redhat.com> Message-ID: <55DC9903.20909@redhat.com> Apologies; I didn't read your original post clearly enough, as your primary concern was with the "name" attribute on the "channel" element, not the "default" attribute on the "channels" element. Plus I was mistaken about "default" not allowing expressions. I'll defer to the clustering guys to make any recommendations about how, if possible, to achieve your desired result. They better understand the use of these attributes. The "name" attribute on the "channel" element definitely can't allow expressions. It forms part of the address of a management resource, and addresses must be fixed. On 8/25/15 10:54 AM, Dennis Brouwer wrote: > Thanks Brain for answering this however I am still a bit puzzled, > > Let me explain: > > On Tue, Aug 25, 2015 at 5:04 PM, Brian Stansberry > > wrote: > > This attribute does not support use of expressions, so any data you > provide is evaluated simply as a string. > > > "This attribute" most likely refers to the name attribute in name="ee"> if I interpret your sentence correctly. If so, why not create > an extra attribute CLUSTER_NAME next to the existing STACK and MODULE > attributes and use the CLUSTER_NAME to create the JChannel. Using the > current configuration model all containers start up with default cluster > name "ee" unless the standalone*.xml file is edited beforehand. This is > practically undoable because the cluster name defaults to the name of > the channel used and I didn't find a way to overrule this (I might have > overlooked something of course). > > The only way to make distinct clusters is to add a bunch of pre-defined > channel definitions and change the channels default. example: > > / // /// > // > ///// > // // //... /// > > And then select one of the names using the > -Dcustom_clustername=[|whee|foo] startup property. However the desired > behavior is to be flexible and provide a random name at startup time. > > > It doesn't support expressions because it is what we call a "model > reference" attribute. It's value refers to another element in the > configuration model. We do not allow expressions in those attributes > because it is not possible to have all the necessary data to resolve the > expression at the points in time when the correctness of the model must > be validated. > > On 8/25/15 9:31 AM, Dennis Brouwer wrote: > > Dear reader, > > > > We recently moved to Wildfly 9.0.1.Final (from 8.2.0) for testing and > > stumbled upon a bug regarding expression evaluation in the > standalone*.xml. > > > > Let me give an example for the following subsystem: > > > > > > > > > > > > ... > > > > > > Since we have several deployment stages on one physical server we > need > > to separate the clusters by using a distinct name for each one of the > > stages deployed. Hence we introduced a startup property to be > > substituted in the standalone*.xml configuration like following > snippet > > clarifies: > > > > > > > > > > > > ... > > > > > > Using this approach however fails to start the container because the > > channels default attribute is properly evaluated to "ee" (accoding to > > specs). However the channel name attribute is not evaluated at > all and > > is registered as "${custom_clustername:ee}" (without the quotes). > > > > I took the liberty to dig in the class: > > > org.jboss.as.clustering.jgroups.subsystem.JGroupsSubsystemXMLReader and > > manually do the expression evaluation for the channel name. At first > > glance this seems to work however the container rewrites the > > standalone*.xml file at a certain moment resulting in this snippet: > > > > > > > > > > > > ... > > > > > > Which on subsequent container starts and when using the > > -Dcustom_clustername=whee startup property causes a problem > because the > > channels default is evaluated to "whee" and the channel name > remains "ee". > > > > > > So my questions are: > > > > 1] How to solve this issue in a correct way? > > 2] Can somebody provide another mechanism to configure a non default > > channel name on startup? > > > > > > -- > > Best regards, > > > > *Dennis Brouwer* > > Extraordinary Goalkeeper > > > > > > > > > > ZEEF - Kizitos B.V. > > Amstelboulevard 184 > > 1096 HM Amsterdam > > www.ZEEF.com > > US:+1 (415) 992-9409 > > NL:+31 (085) 888-3186 > > > > > > _______________________________________________ > > 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 > > > > > -- > Best regards, > > *Dennis Brouwer* > Extraordinary Goalkeeper > > > > > ZEEF - Kizitos B.V. > Amstelboulevard 184 > 1096 HM Amsterdam > www.ZEEF.com > US: +1 (415) 992-9409 > NL: +31 (085) 888-3186 -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From ehugonne at redhat.com Tue Aug 25 13:47:40 2015 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Tue, 25 Aug 2015 19:47:40 +0200 Subject: [wildfly-dev] Widlfly 9.0.1.Final - subsystem expression evaluation not entirely water proof In-Reply-To: References: <55DC83F9.9050100@redhat.com> Message-ID: <55DCAA3C.6030008@redhat.com> Hi, Maybe you could use the admin-only mode to create your channel with your random name and then restart the server in normal mode. Emmanuel Le 25/08/2015 17:54, Dennis Brouwer a ?crit : > Thanks Brain for answering this however I am still a bit puzzled, > > Let me explain: > > On Tue, Aug 25, 2015 at 5:04 PM, Brian Stansberry > wrote: > > This attribute does not support use of expressions, so any data you > provide is evaluated simply as a string. > > > "This attribute" most likely refers to the name attribute in if I interpret your sentence correctly. If so, why not > create an extra attribute CLUSTER_NAME next to the existing STACK and MODULE attributes and use the CLUSTER_NAME to create the JChannel. > Using the current configuration model all containers start up with default cluster name "ee" unless the standalone*.xml file is edited > beforehand. This is practically undoable because the cluster name defaults to the name of the channel used and I didn't find a way to > overrule this (I might have overlooked something of course). > > The only way to make distinct clusters is to add a bunch of pre-defined channel definitions and change the channels default. example: > > / // /// > // > ///// > // // //... /// > > And then select one of the names using the -Dcustom_clustername=[|whee|foo] startup property. However the desired behavior is to be flexible > and provide a random name at startup time. > > > It doesn't support expressions because it is what we call a "model > reference" attribute. It's value refers to another element in the > configuration model. We do not allow expressions in those attributes > because it is not possible to have all the necessary data to resolve the > expression at the points in time when the correctness of the model must > be validated. > > On 8/25/15 9:31 AM, Dennis Brouwer wrote: > > Dear reader, > > > > We recently moved to Wildfly 9.0.1.Final (from 8.2.0) for testing and > > stumbled upon a bug regarding expression evaluation in the standalone*.xml. > > > > Let me give an example for the following subsystem: > > > > > > > > > > > > ... > > > > > > Since we have several deployment stages on one physical server we need > > to separate the clusters by using a distinct name for each one of the > > stages deployed. Hence we introduced a startup property to be > > substituted in the standalone*.xml configuration like following snippet > > clarifies: > > > > > > > > > > > > ... > > > > > > Using this approach however fails to start the container because the > > channels default attribute is properly evaluated to "ee" (accoding to > > specs). However the channel name attribute is not evaluated at all and > > is registered as "${custom_clustername:ee}" (without the quotes). > > > > I took the liberty to dig in the class: > > org.jboss.as.clustering.jgroups.subsystem.JGroupsSubsystemXMLReader and > > manually do the expression evaluation for the channel name. At first > > glance this seems to work however the container rewrites the > > standalone*.xml file at a certain moment resulting in this snippet: > > > > > > > > > > > > ... > > > > > > Which on subsequent container starts and when using the > > -Dcustom_clustername=whee startup property causes a problem because the > > channels default is evaluated to "whee" and the channel name remains "ee". > > > > > > So my questions are: > > > > 1] How to solve this issue in a correct way? > > 2] Can somebody provide another mechanism to configure a non default > > channel name on startup? > > > > > > -- > > Best regards, > > > > *Dennis Brouwer* > > Extraordinary Goalkeeper > > > > > > > > > > ZEEF - Kizitos B.V. > > Amstelboulevard 184 > > 1096 HM Amsterdam > > www.ZEEF.com > > US: +1 (415) 992-9409 > > NL: +31 (085) 888-3186 > > > > > > _______________________________________________ > > 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 > > > > > -- > Best regards, > > *Dennis Brouwer* > Extraordinary Goalkeeper > > > > > ZEEF - Kizitos B.V. > Amstelboulevard 184 > 1096 HM Amsterdam > www.ZEEF.com > US: +1 (415) 992-9409 > NL: +31 (085) 888-3186 > > > _______________________________________________ > 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/20150825/be6b7064/attachment.bin From dennis.brouwer at kizitos.com Tue Aug 25 14:52:43 2015 From: dennis.brouwer at kizitos.com (Dennis Brouwer) Date: Tue, 25 Aug 2015 20:52:43 +0200 Subject: [wildfly-dev] Widlfly 9.0.1.Final - subsystem expression evaluation not entirely water proof In-Reply-To: <55DCAA3C.6030008@redhat.com> References: <55DC83F9.9050100@redhat.com> <55DCAA3C.6030008@redhat.com> Message-ID: Hi Emmanuel, Thanks for the suggestion however this is unfortunately not possible, we have a bunch developers with Eclipse and JBoss Tools installed and they switch to a different stage with only one startup property. I think that indeed adding a cluster attribute to the channel element that allows the JChannel name to be configured is the cleanest solution. If the cluster attribute is omitted then JChannel name should default to the channel name. On Tue, Aug 25, 2015 at 7:47 PM, Emmanuel Hugonnet wrote: > Hi, > Maybe you could use the admin-only mode to create your channel with your > random name and then restart the server in normal mode. > Emmanuel > > Le 25/08/2015 17:54, Dennis Brouwer a ?crit : > > Thanks Brain for answering this however I am still a bit puzzled, > > > > Let me explain: > > > > On Tue, Aug 25, 2015 at 5:04 PM, Brian Stansberry < > brian.stansberry at redhat.com > wrote: > > > > This attribute does not support use of expressions, so any data you > > provide is evaluated simply as a string. > > > > > > "This attribute" most likely refers to the name attribute in name="ee"> if I interpret your sentence correctly. If so, why not > > create an extra attribute CLUSTER_NAME next to the existing STACK and > MODULE attributes and use the CLUSTER_NAME to create the JChannel. > > Using the current configuration model all containers start up with > default cluster name "ee" unless the standalone*.xml file is edited > > beforehand. This is practically undoable because the cluster name > defaults to the name of the channel used and I didn't find a way to > > overrule this (I might have overlooked something of course). > > > > The only way to make distinct clusters is to add a bunch of pre-defined > channel definitions and change the channels default. example: > > > > / // default="${custom_clustername:ee}"> /// > > // > > ///// > > // // //... /// > > > > And then select one of the names using the > -Dcustom_clustername=[|whee|foo] startup property. However the desired > behavior is to be flexible > > and provide a random name at startup time. > > > > > > It doesn't support expressions because it is what we call a "model > > reference" attribute. It's value refers to another element in the > > configuration model. We do not allow expressions in those attributes > > because it is not possible to have all the necessary data to resolve > the > > expression at the points in time when the correctness of the model > must > > be validated. > > > > On 8/25/15 9:31 AM, Dennis Brouwer wrote: > > > Dear reader, > > > > > > We recently moved to Wildfly 9.0.1.Final (from 8.2.0) for testing > and > > > stumbled upon a bug regarding expression evaluation in the > standalone*.xml. > > > > > > Let me give an example for the following subsystem: > > > > > > > > > > > > > > > > > > ... > > > > > > > > > Since we have several deployment stages on one physical server we > need > > > to separate the clusters by using a distinct name for each one of > the > > > stages deployed. Hence we introduced a startup property to be > > > substituted in the standalone*.xml configuration like following > snippet > > > clarifies: > > > > > > > > > > > > > > > > > > ... > > > > > > > > > Using this approach however fails to start the container because > the > > > channels default attribute is properly evaluated to "ee" (accoding > to > > > specs). However the channel name attribute is not evaluated at all > and > > > is registered as "${custom_clustername:ee}" (without the quotes). > > > > > > I took the liberty to dig in the class: > > > > org.jboss.as.clustering.jgroups.subsystem.JGroupsSubsystemXMLReader and > > > manually do the expression evaluation for the channel name. At > first > > > glance this seems to work however the container rewrites the > > > standalone*.xml file at a certain moment resulting in this snippet: > > > > > > > > > > > > > > > > > > ... > > > > > > > > > Which on subsequent container starts and when using the > > > -Dcustom_clustername=whee startup property causes a problem > because the > > > channels default is evaluated to "whee" and the channel name > remains "ee". > > > > > > > > > So my questions are: > > > > > > 1] How to solve this issue in a correct way? > > > 2] Can somebody provide another mechanism to configure a non > default > > > channel name on startup? > > > > > > > > > -- > > > Best regards, > > > > > > *Dennis Brouwer* > > > Extraordinary Goalkeeper > > > > > > > > > > > > > > > ZEEF - Kizitos B.V. > > > Amstelboulevard 184 > > > 1096 HM Amsterdam > > > www.ZEEF.com > > > US: +1 (415) 992-9409 > > > NL: +31 (085) 888-3186 > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > > > > -- > > Best regards, > > > > *Dennis Brouwer* > > Extraordinary Goalkeeper > > > > > > > > > > ZEEF - Kizitos B.V. > > Amstelboulevard 184 > > 1096 HM Amsterdam > > www.ZEEF.com > > US: +1 (415) 992-9409 > > NL: +31 (085) 888-3186 > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- Best regards, *Dennis Brouwer* Extraordinary Goalkeeper ZEEF - Kizitos B.V. Amstelboulevard 184 1096 HM Amsterdam www.ZEEF.com US: +1 (415) 992-9409 NL: +31 (085) 888-3186 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150825/cf81a316/attachment-0001.html From paul.ferraro at redhat.com Tue Aug 25 15:34:43 2015 From: paul.ferraro at redhat.com (Paul Ferraro) Date: Tue, 25 Aug 2015 15:34:43 -0400 (EDT) Subject: [wildfly-dev] Widlfly 9.0.1.Final - subsystem expression evaluation not entirely water proof In-Reply-To: References: <55DC83F9.9050100@redhat.com> <55DCAA3C.6030008@redhat.com> Message-ID: <2105661258.17038924.1440531283581.JavaMail.zimbra@redhat.com> Hi Dennis, Ultimately, I think your suggestion (i.e. decoupling the name of the JGroups cluster from the name of the channel) is a good one. I've opened a jira for this: https://issues.jboss.org/browse/WFLY-5202 I can implement this later today. Paul ----- Original Message ----- > From: "Dennis Brouwer" > To: "Emmanuel Hugonnet" > Cc: wildfly-dev at lists.jboss.org > Sent: Tuesday, August 25, 2015 2:52:43 PM > Subject: Re: [wildfly-dev] Widlfly 9.0.1.Final - subsystem expression evaluation not entirely water proof > > Hi Emmanuel, > > Thanks for the suggestion however this is unfortunately not possible, we have > a bunch developers with Eclipse and JBoss Tools installed and they switch to > a different stage with only one startup property. I think that indeed adding > a cluster attribute to the channel element that allows the JChannel name to > be configured is the cleanest solution. If the cluster attribute is omitted > then JChannel name should default to the channel name. > > > On Tue, Aug 25, 2015 at 7:47 PM, Emmanuel Hugonnet < ehugonne at redhat.com > > wrote: > > > Hi, > Maybe you could use the admin-only mode to create your channel with your > random name and then restart the server in normal mode. > Emmanuel > > Le 25/08/2015 17:54, Dennis Brouwer a ?crit : > > Thanks Brain for answering this however I am still a bit puzzled, > > > > Let me explain: > > > > On Tue, Aug 25, 2015 at 5:04 PM, Brian Stansberry < > > brian.stansberry at redhat.com > wrote: > > > > This attribute does not support use of expressions, so any data you > > provide is evaluated simply as a string. > > > > > > "This attribute" most likely refers to the name attribute in > name="ee"> if I interpret your sentence correctly. If so, why not > > create an extra attribute CLUSTER_NAME next to the existing STACK and > > MODULE attributes and use the CLUSTER_NAME to create the JChannel. > > Using the current configuration model all containers start up with default > > cluster name "ee" unless the standalone*.xml file is edited > > beforehand. This is practically undoable because the cluster name defaults > > to the name of the channel used and I didn't find a way to > > overrule this (I might have overlooked something of course). > > > > The only way to make distinct clusters is to add a bunch of pre-defined > > channel definitions and change the channels default. example: > > > > / // > default="${custom_clustername:ee}"> /// > > // > > ///// > > // // //... /// > > > > And then select one of the names using the -Dcustom_clustername=[|whee|foo] > > startup property. However the desired behavior is to be flexible > > and provide a random name at startup time. > > > > > > It doesn't support expressions because it is what we call a "model > > reference" attribute. It's value refers to another element in the > > configuration model. We do not allow expressions in those attributes > > because it is not possible to have all the necessary data to resolve the > > expression at the points in time when the correctness of the model must > > be validated. > > > > On 8/25/15 9:31 AM, Dennis Brouwer wrote: > > > Dear reader, > > > > > > We recently moved to Wildfly 9.0.1.Final (from 8.2.0) for testing and > > > stumbled upon a bug regarding expression evaluation in the > > > standalone*.xml. > > > > > > Let me give an example for the following subsystem: > > > > > > > > > > > > > > > > > > ... > > > > > > > > > Since we have several deployment stages on one physical server we need > > > to separate the clusters by using a distinct name for each one of the > > > stages deployed. Hence we introduced a startup property to be > > > substituted in the standalone*.xml configuration like following snippet > > > clarifies: > > > > > > > > > > > > > > > > > > ... > > > > > > > > > Using this approach however fails to start the container because the > > > channels default attribute is properly evaluated to "ee" (accoding to > > > specs). However the channel name attribute is not evaluated at all and > > > is registered as "${custom_clustername:ee}" (without the quotes). > > > > > > I took the liberty to dig in the class: > > > org.jboss.as.clustering.jgroups.subsystem.JGroupsSubsystemXMLReader and > > > manually do the expression evaluation for the channel name. At first > > > glance this seems to work however the container rewrites the > > > standalone*.xml file at a certain moment resulting in this snippet: > > > > > > > > > > > > > > > > > > ... > > > > > > > > > Which on subsequent container starts and when using the > > > -Dcustom_clustername=whee startup property causes a problem because the > > > channels default is evaluated to "whee" and the channel name remains > > > "ee". > > > > > > > > > So my questions are: > > > > > > 1] How to solve this issue in a correct way? > > > 2] Can somebody provide another mechanism to configure a non default > > > channel name on startup? > > > > > > > > > -- > > > Best regards, > > > > > > *Dennis Brouwer* > > > Extraordinary Goalkeeper > > > > > > > > > > > > > > > ZEEF - Kizitos B.V. > > > Amstelboulevard 184 > > > 1096 HM Amsterdam > > > www.ZEEF.com < http://www.ZEEF.com > < http://www.zeef.com/ > > > > US: +1 (415) 992-9409 > > > NL: +31 (085) 888-3186 > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > > > > -- > > Best regards, > > > > *Dennis Brouwer* > > Extraordinary Goalkeeper > > > > > > > > > > ZEEF - Kizitos B.V. > > Amstelboulevard 184 > > 1096 HM Amsterdam > > www.ZEEF.com < http://www.zeef.com/ > > > US: +1 (415) 992-9409 > > NL: +31 (085) 888-3186 > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > -- > Best regards, > > Dennis Brouwer > Extraordinary Goalkeeper > > > > > ZEEF - Kizitos B.V. > Amstelboulevard 184 > 1096 HM Amsterdam > www.ZEEF.com > US: +1 (415) 992-9409 > NL: +31 (085) 888-3186 > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jcacek at redhat.com Wed Aug 26 08:38:41 2015 From: jcacek at redhat.com (Josef Cacek) Date: Wed, 26 Aug 2015 08:38:41 -0400 (EDT) Subject: [wildfly-dev] Permissions in WildFly Core In-Reply-To: <1365725675.10875450.1440585670514.JavaMail.zimbra@redhat.com> Message-ID: <532677388.10903538.1440592721682.JavaMail.zimbra@redhat.com> Hi *, Is there a way how to configure Java security permissions in WildFly Core? If not, is there any reason why not to move the wildfly-security-manager from WildFly into WildFly Core? I'm investigating failing tests in WildFly Core testsuite ([1],[2]) when security manager is enabled. The problem is, security manager is in place and I'm not able to define permissions for deployments - using policy file (configured by java.security.policy system property) doesn't work for me; - putting META-INF/permissions.xml into deployments doesn't help because PermissionsParseProcessor deployment processor is part of wildfly-security-manager (i.e. not in Core) and it is only activated when security-manager subsystem is present. So the tests fail because of AccessControlExceptions on the server side. Any thoughts? As a workaround we can run the Core testsuite against full WildFly and use either in-deployment permissions.xml or configure permissions in subsystem [3] - but both ways have some disadvantages. We either have to put "unnecessary" permissions.xml in WFCORE deployments or we have to use too wide minimum-permissions in security-manager subsystem configuration. [1] https://issues.jboss.org/browse/WFCORE-846 [2] https://issues.jboss.org/browse/JBEAP-526 [3] /subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions, value=[{class=java.security.AllPermission}])") Thanks, -- Josef Cacek From dpospisi at redhat.com Wed Aug 26 09:17:45 2015 From: dpospisi at redhat.com (Dominik Pospisil) Date: Wed, 26 Aug 2015 15:17:45 +0200 Subject: [wildfly-dev] Persisting attributes explicitly set to default values Message-ID: <1488464.sRjxhpeGeV@dhcp-10-40-5-148.brq.redhat.com> Is there any rule saying if an attribute should be persisted if it is explicitly set to it's default value or not? At least some attributes in the legacy web subsystem are persisted in such case and some are not. It seems that the API encourages to choose any of the options. Is there any reason for that? Many thanks, - Dominik From darran.lofthouse at jboss.com Wed Aug 26 09:24:23 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 26 Aug 2015 14:24:23 +0100 Subject: [wildfly-dev] Persisting attributes explicitly set to default values In-Reply-To: <1488464.sRjxhpeGeV@dhcp-10-40-5-148.brq.redhat.com> References: <1488464.sRjxhpeGeV@dhcp-10-40-5-148.brq.redhat.com> Message-ID: <55DDBE07.3010201@jboss.com> The current approach is to let the attribute definition handle writing the attribute and this automatically skips writing if the value is the default value. The legacy web subsystem was written before we had this ability. On 26/08/15 14:17, Dominik Pospisil wrote: > Is there any rule saying if an attribute should be persisted if it is > explicitly set to it's default value or not? > > At least some attributes in the legacy web subsystem are persisted in such > case and some are not. > > It seems that the API encourages to choose any of the options. Is there any > reason for that? > > Many thanks, > > - Dominik > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From tomaz.cerar at gmail.com Wed Aug 26 09:31:57 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 26 Aug 2015 15:31:57 +0200 Subject: [wildfly-dev] Persisting attributes explicitly set to default values In-Reply-To: <55DDBE07.3010201@jboss.com> References: <1488464.sRjxhpeGeV@dhcp-10-40-5-148.brq.redhat.com> <55DDBE07.3010201@jboss.com> Message-ID: There is also https://issues.jboss.org/browse/WFCORE-836 to change current behavior for parsers that are using PersistentResourceXMLParser / PersistentResourceXMLDescription But basically we didn't have any rule about it, at least not in older subsystems, above jira is result of discussion we had recently on the topic. -- tomaz On Wed, Aug 26, 2015 at 3:24 PM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > The current approach is to let the attribute definition handle writing > the attribute and this automatically skips writing if the value is the > default value. > > The legacy web subsystem was written before we had this ability. > > On 26/08/15 14:17, Dominik Pospisil wrote: > > Is there any rule saying if an attribute should be persisted if it is > > explicitly set to it's default value or not? > > > > At least some attributes in the legacy web subsystem are persisted in > such > > case and some are not. > > > > It seems that the API encourages to choose any of the options. Is there > any > > reason for that? > > > > Many thanks, > > > > - Dominik > > _______________________________________________ > > 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/20150826/95afffb6/attachment.html From brian.stansberry at redhat.com Wed Aug 26 09:35:40 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 26 Aug 2015 08:35:40 -0500 Subject: [wildfly-dev] Persisting attributes explicitly set to default values In-Reply-To: <1488464.sRjxhpeGeV@dhcp-10-40-5-148.brq.redhat.com> References: <1488464.sRjxhpeGeV@dhcp-10-40-5-148.brq.redhat.com> Message-ID: <55DDC0AC.6050102@redhat.com> The standard behavior is to persist user provided values, regardless of whether they match the default. If the user didn't specify a value and thus relied upon the default, then we don't persist the default. The downside is the xml config contains more data than strictly necessary. The upside is the value often originally comes from the user provided config document, and if we don't write it back when persisting the doc following some unrelated change, we've changed that document unnecessarily. We "share" that document with the end user, so I want to avoid altering it in ways that are not required. This is also why our xml marshaling should always marshal things back in the order they are declared in the xsd, and the standard config docs we ship should also follow that order. We have no way to preserve the original order in which unrelated things were parsed, so if the user doesn't follow xsd order we'll write back in a different order. But at least the order we write in will be predictable. On 8/26/15 8:17 AM, Dominik Pospisil wrote: > Is there any rule saying if an attribute should be persisted if it is > explicitly set to it's default value or not? > > At least some attributes in the legacy web subsystem are persisted in such > case and some are not. > > It seems that the API encourages to choose any of the options. Is there any > reason for that? > > Many thanks, > > - Dominik > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Aug 26 09:49:08 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 26 Aug 2015 08:49:08 -0500 Subject: [wildfly-dev] Permissions in WildFly Core In-Reply-To: <532677388.10903538.1440592721682.JavaMail.zimbra@redhat.com> References: <532677388.10903538.1440592721682.JavaMail.zimbra@redhat.com> Message-ID: <55DDC3D4.1090909@redhat.com> Just some data, as I know distribution size is a significant factor in deciding what goes into WildFly Core: The org.wildfly.extension.security.manager module itself is 45KB unzipped, so not much of a concern. However, it depends on org.jboss.metadata.common, which is 475KB and isn't itself present in WildFly Core. All its other deps are present in WildFly Core. On 8/26/15 7:38 AM, Josef Cacek wrote: > Hi *, > > Is there a way how to configure Java security permissions in WildFly Core? > If not, is there any reason why not to move the wildfly-security-manager from WildFly into WildFly Core? > > I'm investigating failing tests in WildFly Core testsuite ([1],[2]) when security manager is enabled. > > The problem is, security manager is in place and I'm not able to define permissions for deployments > - using policy file (configured by java.security.policy system property) doesn't work for me; > - putting META-INF/permissions.xml into deployments doesn't help because PermissionsParseProcessor deployment processor is part of wildfly-security-manager (i.e. not in Core) and it is only activated when security-manager subsystem is present. > > So the tests fail because of AccessControlExceptions on the server side. > > Any thoughts? > > As a workaround we can run the Core testsuite against full WildFly and use either in-deployment permissions.xml or configure permissions in subsystem [3] - but both ways have some disadvantages. > We either have to put "unnecessary" permissions.xml in WFCORE deployments or we have to use too wide minimum-permissions in security-manager subsystem configuration. > > [1] https://issues.jboss.org/browse/WFCORE-846 > [2] https://issues.jboss.org/browse/JBEAP-526 > [3] /subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions, value=[{class=java.security.AllPermission}])") > > Thanks, > > -- Josef Cacek > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Aug 26 09:56:44 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 26 Aug 2015 08:56:44 -0500 Subject: [wildfly-dev] Permissions in WildFly Core In-Reply-To: <55DDC3D4.1090909@redhat.com> References: <532677388.10903538.1440592721682.JavaMail.zimbra@redhat.com> <55DDC3D4.1090909@redhat.com> Message-ID: <55DDC59C.5010205@redhat.com> On 8/26/15 8:49 AM, Brian Stansberry wrote: > Just some data, as I know distribution size is a significant factor in > deciding what goes into WildFly Core: > > The org.wildfly.extension.security.manager module itself is 45KB > unzipped, so not much of a concern. > > However, it depends on org.jboss.metadata.common, which is 475KB and > isn't itself present in WildFly Core. The requirement for org.jboss.metadata.common looks pretty simple to eliminate. It's just using a bit of what looks like easily duplicated utility code. > > All its other deps are present in WildFly Core. > > On 8/26/15 7:38 AM, Josef Cacek wrote: >> Hi *, >> >> Is there a way how to configure Java security permissions in WildFly Core? >> If not, is there any reason why not to move the wildfly-security-manager from WildFly into WildFly Core? >> >> I'm investigating failing tests in WildFly Core testsuite ([1],[2]) when security manager is enabled. >> >> The problem is, security manager is in place and I'm not able to define permissions for deployments >> - using policy file (configured by java.security.policy system property) doesn't work for me; >> - putting META-INF/permissions.xml into deployments doesn't help because PermissionsParseProcessor deployment processor is part of wildfly-security-manager (i.e. not in Core) and it is only activated when security-manager subsystem is present. >> >> So the tests fail because of AccessControlExceptions on the server side. >> >> Any thoughts? >> >> As a workaround we can run the Core testsuite against full WildFly and use either in-deployment permissions.xml or configure permissions in subsystem [3] - but both ways have some disadvantages. >> We either have to put "unnecessary" permissions.xml in WFCORE deployments or we have to use too wide minimum-permissions in security-manager subsystem configuration. >> >> [1] https://issues.jboss.org/browse/WFCORE-846 >> [2] https://issues.jboss.org/browse/JBEAP-526 >> [3] /subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions, value=[{class=java.security.AllPermission}])") >> >> Thanks, >> >> -- Josef Cacek >> _______________________________________________ >> 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 tomaz.cerar at gmail.com Wed Aug 26 10:00:16 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 26 Aug 2015 16:00:16 +0200 Subject: [wildfly-dev] Permissions in WildFly Core In-Reply-To: <55DDC59C.5010205@redhat.com> References: <532677388.10903538.1440592721682.JavaMail.zimbra@redhat.com> <55DDC3D4.1090909@redhat.com> <55DDC59C.5010205@redhat.com> Message-ID: Also AFAIR, security manager subsystem implements EE7 security manager(permissions.xml) support. and as such doesn't belong to core. On Wed, Aug 26, 2015 at 3:56 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > On 8/26/15 8:49 AM, Brian Stansberry wrote: > > Just some data, as I know distribution size is a significant factor in > > deciding what goes into WildFly Core: > > > > The org.wildfly.extension.security.manager module itself is 45KB > > unzipped, so not much of a concern. > > > > However, it depends on org.jboss.metadata.common, which is 475KB and > > isn't itself present in WildFly Core. > > The requirement for org.jboss.metadata.common looks pretty simple to > eliminate. It's just using a bit of what looks like easily duplicated > utility code. > > > > > All its other deps are present in WildFly Core. > > > > On 8/26/15 7:38 AM, Josef Cacek wrote: > >> Hi *, > >> > >> Is there a way how to configure Java security permissions in WildFly > Core? > >> If not, is there any reason why not to move the > wildfly-security-manager from WildFly into WildFly Core? > >> > >> I'm investigating failing tests in WildFly Core testsuite ([1],[2]) > when security manager is enabled. > >> > >> The problem is, security manager is in place and I'm not able to define > permissions for deployments > >> - using policy file (configured by java.security.policy system > property) doesn't work for me; > >> - putting META-INF/permissions.xml into deployments doesn't help > because PermissionsParseProcessor deployment processor is part of > wildfly-security-manager (i.e. not in Core) and it is only activated when > security-manager subsystem is present. > >> > >> So the tests fail because of AccessControlExceptions on the server side. > >> > >> Any thoughts? > >> > >> As a workaround we can run the Core testsuite against full WildFly and > use either in-deployment permissions.xml or configure permissions in > subsystem [3] - but both ways have some disadvantages. > >> We either have to put "unnecessary" permissions.xml in WFCORE > deployments or we have to use too wide minimum-permissions in > security-manager subsystem configuration. > >> > >> [1] https://issues.jboss.org/browse/WFCORE-846 > >> [2] https://issues.jboss.org/browse/JBEAP-526 > >> [3] > /subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions, > value=[{class=java.security.AllPermission}])") > >> > >> Thanks, > >> > >> -- Josef Cacek > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150826/43c62cb6/attachment.html From brian.stansberry at redhat.com Wed Aug 26 10:27:00 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 26 Aug 2015 09:27:00 -0500 Subject: [wildfly-dev] Permissions in WildFly Core In-Reply-To: References: <532677388.10903538.1440592721682.JavaMail.zimbra@redhat.com> <55DDC3D4.1090909@redhat.com> <55DDC59C.5010205@redhat.com> Message-ID: <55DDCCB4.7060808@redhat.com> Right. I've been looking into the size impacts, so since those appear to be solvable, this discussion can just focus on whether it belongs. On 8/26/15 9:00 AM, Toma? Cerar wrote: > Also AFAIR, security manager subsystem implements EE7 security > manager(permissions.xml) support. > and as such doesn't belong to core. > > On Wed, Aug 26, 2015 at 3:56 PM, Brian Stansberry > > wrote: > > On 8/26/15 8:49 AM, Brian Stansberry wrote: > > Just some data, as I know distribution size is a significant factor in > > deciding what goes into WildFly Core: > > > > The org.wildfly.extension.security.manager module itself is 45KB > > unzipped, so not much of a concern. > > > > However, it depends on org.jboss.metadata.common, which is 475KB and > > isn't itself present in WildFly Core. > > The requirement for org.jboss.metadata.common looks pretty simple to > eliminate. It's just using a bit of what looks like easily duplicated > utility code. > > > > > All its other deps are present in WildFly Core. > > > > On 8/26/15 7:38 AM, Josef Cacek wrote: > >> Hi *, > >> > >> Is there a way how to configure Java security permissions in > WildFly Core? > >> If not, is there any reason why not to move the > wildfly-security-manager from WildFly into WildFly Core? > >> > >> I'm investigating failing tests in WildFly Core testsuite > ([1],[2]) when security manager is enabled. > >> > >> The problem is, security manager is in place and I'm not able to > define permissions for deployments > >> - using policy file (configured by java.security.policy system > property) doesn't work for me; > >> - putting META-INF/permissions.xml into deployments doesn't help > because PermissionsParseProcessor deployment processor is part of > wildfly-security-manager (i.e. not in Core) and it is only activated > when security-manager subsystem is present. > >> > >> So the tests fail because of AccessControlExceptions on the > server side. > >> > >> Any thoughts? > >> > >> As a workaround we can run the Core testsuite against full > WildFly and use either in-deployment permissions.xml or configure > permissions in subsystem [3] - but both ways have some disadvantages. > >> We either have to put "unnecessary" permissions.xml in WFCORE > deployments or we have to use too wide minimum-permissions in > security-manager subsystem configuration. > >> > >> [1] https://issues.jboss.org/browse/WFCORE-846 > >> [2] https://issues.jboss.org/browse/JBEAP-526 > >> [3] > /subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions, > value=[{class=java.security.AllPermission}])") > >> > >> Thanks, > >> > >> -- Josef Cacek > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Aug 26 15:19:04 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 26 Aug 2015 14:19:04 -0500 Subject: [wildfly-dev] Perf tip for folks writing management code Message-ID: <55DE1128.6060902@redhat.com> If you're writing code that manipulates potentially large chunks of the management model, be cautious of the following: 1) org.jboss.as.controller.Registry.Tools.readModel(final Resource resource) This makes a deep clone of all the DMR model nodes in the given resource tree. That may be a good thing, but is expensive with large trees, so be aware. 2) org.jboss.dmr.ModelNode.asPropertyList() For each Property in the returned list, the 'value' member is a deep clone of the corresponding element in the original model node. So, again expensive with large trees, so be aware. You can replace this: for (Property prop : node.asPropertyList() { String name = prop.getName(); ModelNode value = prop.getValue(); ... do something with name and value } with for (String name : node.keys()) { ModelNode value = node.get(name); ... do something with name and value } I'll fix a few high impact cases of this usage. Please resist the urge to send in lots of refactoring PRs until WF 10 is done. ;) -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Wed Aug 26 18:53:34 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 26 Aug 2015 17:53:34 -0500 Subject: [wildfly-dev] Perf tip for folks writing management code In-Reply-To: <55DE1128.6060902@redhat.com> References: <55DE1128.6060902@redhat.com> Message-ID: <55DE436E.2040301@redhat.com> On 8/26/15 2:19 PM, Brian Stansberry wrote: > If you're writing code that manipulates potentially large chunks of the > management model, be cautious of the following: > > 1) org.jboss.as.controller.Registry.Tools.readModel(final Resource resource) > > This makes a deep clone of all the DMR model nodes in the given resource > tree. That may be a good thing, but is expensive with large trees, so be > aware. > > 2) org.jboss.dmr.ModelNode.asPropertyList() > > For each Property in the returned list, the 'value' member is a deep > clone of the corresponding element in the original model node. So, again > expensive with large trees, so be aware. > > You can replace this: > > for (Property prop : node.asPropertyList() { > String name = prop.getName(); > ModelNode value = prop.getValue(); > ... do something with name and value > } > > with > > for (String name : node.keys()) { > ModelNode value = node.get(name); > ... do something with name and value > } Note: this is not the right thing to do if node.getType() == ModelType.LIST with each list element a ModelType.PROPERTY. The keys() and get(String) methods are not supported for nodes of that type. These are unusual in the WildFly model though, other than the "address" node of an operation object. And that node is usually is handled by kernel code anyway. > > I'll fix a few high impact cases of this usage. > > Please resist the urge to send in lots of refactoring PRs until WF 10 is > done. ;) > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From giriraj.sharma27 at gmail.com Thu Aug 27 00:16:04 2015 From: giriraj.sharma27 at gmail.com (Giriraj Sharma) Date: Thu, 27 Aug 2015 09:46:04 +0530 Subject: [wildfly-dev] Wildfly SSL and mutual SSL authentication quickstarts Message-ID: Hi, I had a look at wildfly quickstarts[1]. If it looks fine, I would like to add a few Wildfly SSL quickstarts like #1. A simple helloworld or helloworld-rs or helloworld-html5 app or all of these demonstrating enabling SSL over wildfly. (configuring keystore, https listener) #2. A simple helloworld or helloworld-rs or helloworld-html5 app or all of these demonstrating enabling mutual client authentication via SSL. (configuring keystore, truststore and https listener) #3. Securing war apps [a simple helloworld or helloworld-rs or helloworld-html5 app or all of these ] deployed over wildfly (Configuring keystore, truststore, https-listener and security-domain using login modules(CertificateRoles)) [1] https://github.com/wildfly/quickstart -- Giriraj Sharma about.me/girirajsharma Giriraj Sharma, Department of Computer Science National Institute of Technology Hamirpur Himachal Pradesh, India 177005 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150827/dfa53602/attachment-0001.html From jcacek at redhat.com Thu Aug 27 03:16:13 2015 From: jcacek at redhat.com (Josef Cacek) Date: Thu, 27 Aug 2015 03:16:13 -0400 (EDT) Subject: [wildfly-dev] Permissions in WildFly Core In-Reply-To: References: <532677388.10903538.1440592721682.JavaMail.zimbra@redhat.com> <55DDC3D4.1090909@redhat.com> <55DDC59C.5010205@redhat.com> Message-ID: <187427770.11137135.1440659773835.JavaMail.zimbra@redhat.com> The problem is that the WildFlySecurityManager is in the Core (used when you start it with -secmgr argument), but I don't see a way how to configure permissions for it without the subsystem. For me it's fine to use the old-school policy file with WF Core - I've tried it ... without success. -- josef ----- Original Message ----- > From: "Toma? Cerar" > To: "Brian Stansberry" > Cc: wildfly-dev at lists.jboss.org > Sent: Wednesday, August 26, 2015 4:00:16 PM > Subject: Re: [wildfly-dev] Permissions in WildFly Core > Also AFAIR, security manager subsystem implements EE7 security > manager(permissions.xml) support. > and as such doesn't belong to core. > On Wed, Aug 26, 2015 at 3:56 PM, Brian Stansberry < > brian.stansberry at redhat.com > wrote: > > On 8/26/15 8:49 AM, Brian Stansberry wrote: > > > > Just some data, as I know distribution size is a significant factor in > > > > deciding what goes into WildFly Core: > > > > > > > > The org.wildfly.extension.security.manager module itself is 45KB > > > > unzipped, so not much of a concern. > > > > > > > > However, it depends on org.jboss.metadata.common, which is 475KB and > > > > isn't itself present in WildFly Core. > > > The requirement for org.jboss.metadata.common looks pretty simple to > > > eliminate. It's just using a bit of what looks like easily duplicated > > > utility code. > > > > > > > > All its other deps are present in WildFly Core. > > > > > > > > On 8/26/15 7:38 AM, Josef Cacek wrote: > > > >> Hi *, > > > >> > > > >> Is there a way how to configure Java security permissions in WildFly > > >> Core? > > > >> If not, is there any reason why not to move the wildfly-security-manager > > >> from WildFly into WildFly Core? > > > >> > > > >> I'm investigating failing tests in WildFly Core testsuite ([1],[2]) when > > >> security manager is enabled. > > > >> > > > >> The problem is, security manager is in place and I'm not able to define > > >> permissions for deployments > > > >> - using policy file (configured by java.security.policy system property) > > >> doesn't work for me; > > > >> - putting META-INF/permissions.xml into deployments doesn't help because > > >> PermissionsParseProcessor deployment processor is part of > > >> wildfly-security-manager (i.e. not in Core) and it is only activated > > >> when > > >> security-manager subsystem is present. > > > >> > > > >> So the tests fail because of AccessControlExceptions on the server side. > > > >> > > > >> Any thoughts? > > > >> > > > >> As a workaround we can run the Core testsuite against full WildFly and > > >> use > > >> either in-deployment permissions.xml or configure permissions in > > >> subsystem [3] - but both ways have some disadvantages. > > > >> We either have to put "unnecessary" permissions.xml in WFCORE > > >> deployments > > >> or we have to use too wide minimum-permissions in security-manager > > >> subsystem configuration. > > > >> > > > >> [1] https://issues.jboss.org/browse/WFCORE-846 > > > >> [2] https://issues.jboss.org/browse/JBEAP-526 > > > >> [3] > > >> /subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions, > > >> value=[{class=java.security.AllPermission}])") > > > >> > > > >> Thanks, > > > >> > > > >> -- Josef Cacek > > > >> _______________________________________________ > > > >> wildfly-dev mailing list > > > >> wildfly-dev at lists.jboss.org > > > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > >> > > > > > > > > > > > -- > > > Brian Stansberry > > > Senior Principal Software Engineer > > > JBoss by Red Hat > > > _______________________________________________ > > > wildfly-dev mailing list > > > wildfly-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Thu Aug 27 07:08:51 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Thu, 27 Aug 2015 07:08:51 -0400 (EDT) Subject: [wildfly-dev] Permissions in WildFly Core In-Reply-To: References: <532677388.10903538.1440592721682.JavaMail.zimbra@redhat.com> <55DDC3D4.1090909@redhat.com> <55DDC59C.5010205@redhat.com> Message-ID: That might actually be ok, since we aren't talking about a Java API, and there are no reps on other specs. However I agree that is wierd. Alternatively we could add different format/schema but I suspect it would look just like permissions.xml. > On Aug 26, 2015, at 9:00 AM, Toma? Cerar wrote: > > Also AFAIR, security manager subsystem implements EE7 security manager(permissions.xml) support. > and as such doesn't belong to core. > >> On Wed, Aug 26, 2015 at 3:56 PM, Brian Stansberry wrote: >> On 8/26/15 8:49 AM, Brian Stansberry wrote: >> > Just some data, as I know distribution size is a significant factor in >> > deciding what goes into WildFly Core: >> > >> > The org.wildfly.extension.security.manager module itself is 45KB >> > unzipped, so not much of a concern. >> > >> > However, it depends on org.jboss.metadata.common, which is 475KB and >> > isn't itself present in WildFly Core. >> >> The requirement for org.jboss.metadata.common looks pretty simple to >> eliminate. It's just using a bit of what looks like easily duplicated >> utility code. >> >> > >> > All its other deps are present in WildFly Core. >> > >> > On 8/26/15 7:38 AM, Josef Cacek wrote: >> >> Hi *, >> >> >> >> Is there a way how to configure Java security permissions in WildFly Core? >> >> If not, is there any reason why not to move the wildfly-security-manager from WildFly into WildFly Core? >> >> >> >> I'm investigating failing tests in WildFly Core testsuite ([1],[2]) when security manager is enabled. >> >> >> >> The problem is, security manager is in place and I'm not able to define permissions for deployments >> >> - using policy file (configured by java.security.policy system property) doesn't work for me; >> >> - putting META-INF/permissions.xml into deployments doesn't help because PermissionsParseProcessor deployment processor is part of wildfly-security-manager (i.e. not in Core) and it is only activated when security-manager subsystem is present. >> >> >> >> So the tests fail because of AccessControlExceptions on the server side. >> >> >> >> Any thoughts? >> >> >> >> As a workaround we can run the Core testsuite against full WildFly and use either in-deployment permissions.xml or configure permissions in subsystem [3] - but both ways have some disadvantages. >> >> We either have to put "unnecessary" permissions.xml in WFCORE deployments or we have to use too wide minimum-permissions in security-manager subsystem configuration. >> >> >> >> [1] https://issues.jboss.org/browse/WFCORE-846 >> >> [2] https://issues.jboss.org/browse/JBEAP-526 >> >> [3] /subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions, value=[{class=java.security.AllPermission}])") >> >> >> >> Thanks, >> >> >> >> -- Josef Cacek >> >> _______________________________________________ >> >> wildfly-dev mailing list >> >> wildfly-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> > >> > >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150827/42bc761b/attachment.html From tomaz.cerar at gmail.com Thu Aug 27 07:27:58 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 27 Aug 2015 13:27:58 +0200 Subject: [wildfly-dev] Wildfly SSL and mutual SSL authentication quickstarts In-Reply-To: References: Message-ID: Sure that is fine and very welcome. Just make sure you send PR against 10.x branch https://github.com/wildfly/quickstart/tree/10.x -- tomaz On Thu, Aug 27, 2015 at 6:16 AM, Giriraj Sharma wrote: > Hi, > > I had a look at wildfly quickstarts[1]. If it looks fine, I would like to > add a few Wildfly SSL quickstarts like > > #1. A simple helloworld or helloworld-rs or helloworld-html5 app or all of > these demonstrating enabling SSL over wildfly. (configuring keystore, https > listener) > > #2. A simple helloworld or helloworld-rs or helloworld-html5 app or all > of these demonstrating enabling mutual client authentication via SSL. > (configuring keystore, truststore and https listener) > > #3. Securing war apps [a simple helloworld or helloworld-rs or > helloworld-html5 app or all of these ] deployed over wildfly (Configuring > keystore, truststore, https-listener and security-domain using login > modules(CertificateRoles)) > > > [1] https://github.com/wildfly/quickstart > > > > > -- > > Giriraj Sharma > about.me/girirajsharma > > Giriraj Sharma, > Department of Computer Science > National Institute of Technology Hamirpur > Himachal Pradesh, India 177005 > > _______________________________________________ > 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/20150827/e1e38f18/attachment.html From david.lloyd at redhat.com Thu Aug 27 09:31:03 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 27 Aug 2015 08:31:03 -0500 Subject: [wildfly-dev] Permissions in WildFly Core In-Reply-To: References: <532677388.10903538.1440592721682.JavaMail.zimbra@redhat.com> <55DDC3D4.1090909@redhat.com> <55DDC59C.5010205@redhat.com> Message-ID: <55DF1117.5070408@redhat.com> The security manager subsystem should definitely be in core. It only has a casual association with Java EE 7 and there's really no practical way to run under a security manager without it. On 08/27/2015 06:08 AM, Jason T. Greene wrote: > That might actually be ok, since we aren't talking about a Java API, and > there are no reps on other specs. However I agree that is wierd. > Alternatively we could add different format/schema but I suspect it > would look just like permissions.xml. > > On Aug 26, 2015, at 9:00 AM, Toma? Cerar > wrote: > >> Also AFAIR, security manager subsystem implements EE7 security >> manager(permissions.xml) support. >> and as such doesn't belong to core. >> >> On Wed, Aug 26, 2015 at 3:56 PM, Brian Stansberry >> > wrote: >> >> On 8/26/15 8:49 AM, Brian Stansberry wrote: >> > Just some data, as I know distribution size is a significant factor in >> > deciding what goes into WildFly Core: >> > >> > The org.wildfly.extension.security.manager module itself is 45KB >> > unzipped, so not much of a concern. >> > >> > However, it depends on org.jboss.metadata.common, which is 475KB and >> > isn't itself present in WildFly Core. >> >> The requirement for org.jboss.metadata.common looks pretty simple to >> eliminate. It's just using a bit of what looks like easily duplicated >> utility code. >> >> > >> > All its other deps are present in WildFly Core. >> > >> > On 8/26/15 7:38 AM, Josef Cacek wrote: >> >> Hi *, >> >> >> >> Is there a way how to configure Java security permissions in WildFly Core? >> >> If not, is there any reason why not to move the wildfly-security-manager from WildFly into WildFly Core? >> >> >> >> I'm investigating failing tests in WildFly Core testsuite ([1],[2]) when security manager is enabled. >> >> >> >> The problem is, security manager is in place and I'm not able to define permissions for deployments >> >> - using policy file (configured by java.security.policy system property) doesn't work for me; >> >> - putting META-INF/permissions.xml into deployments doesn't help because PermissionsParseProcessor deployment processor is part of wildfly-security-manager (i.e. not in Core) and it is only activated when security-manager subsystem is present. >> >> >> >> So the tests fail because of AccessControlExceptions on the server side. >> >> >> >> Any thoughts? >> >> >> >> As a workaround we can run the Core testsuite against full WildFly and use either in-deployment permissions.xml or configure permissions in subsystem [3] - but both ways have some disadvantages. >> >> We either have to put "unnecessary" permissions.xml in WFCORE deployments or we have to use too wide minimum-permissions in security-manager subsystem configuration. >> >> >> >> [1]https://issues.jboss.org/browse/WFCORE-846 >> >> [2]https://issues.jboss.org/browse/JBEAP-526 >> >> [3] /subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions, value=[{class=java.security.AllPermission}])") >> >> >> >> Thanks, >> >> >> >> -- Josef Cacek >> >> _______________________________________________ >> >> wildfly-dev mailing list >> >>wildfly-dev at lists.jboss.org >> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> > >> > >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML From jcacek at redhat.com Fri Aug 28 03:54:53 2015 From: jcacek at redhat.com (Josef Cacek) Date: Fri, 28 Aug 2015 03:54:53 -0400 (EDT) Subject: [wildfly-dev] Permissions in WildFly Core In-Reply-To: <55DF1117.5070408@redhat.com> References: <532677388.10903538.1440592721682.JavaMail.zimbra@redhat.com> <55DDC3D4.1090909@redhat.com> <55DDC59C.5010205@redhat.com> <55DF1117.5070408@redhat.com> Message-ID: <260644591.11490057.1440748493604.JavaMail.zimbra@redhat.com> Hi, thanks for all your comments. I've created a new JIRA [1] to cover moving the security-manager subsystem from WildFly to the Core. [1] https://issues.jboss.org/browse/WFLY-5227 Regards, -- josef ----- Original Message ----- > From: "David M. Lloyd" > To: wildfly-dev at lists.jboss.org > Sent: Thursday, August 27, 2015 3:31:03 PM > Subject: Re: [wildfly-dev] Permissions in WildFly Core > > The security manager subsystem should definitely be in core. It only > has a casual association with Java EE 7 and there's really no practical > way to run under a security manager without it. > > On 08/27/2015 06:08 AM, Jason T. Greene wrote: > > That might actually be ok, since we aren't talking about a Java API, and > > there are no reps on other specs. However I agree that is wierd. > > Alternatively we could add different format/schema but I suspect it > > would look just like permissions.xml. > > > > On Aug 26, 2015, at 9:00 AM, Toma? Cerar > > wrote: > > > >> Also AFAIR, security manager subsystem implements EE7 security > >> manager(permissions.xml) support. > >> and as such doesn't belong to core. > >> > >> On Wed, Aug 26, 2015 at 3:56 PM, Brian Stansberry > >> > wrote: > >> > >> On 8/26/15 8:49 AM, Brian Stansberry wrote: > >> > Just some data, as I know distribution size is a significant factor > >> > in > >> > deciding what goes into WildFly Core: > >> > > >> > The org.wildfly.extension.security.manager module itself is 45KB > >> > unzipped, so not much of a concern. > >> > > >> > However, it depends on org.jboss.metadata.common, which is 475KB and > >> > isn't itself present in WildFly Core. > >> > >> The requirement for org.jboss.metadata.common looks pretty simple to > >> eliminate. It's just using a bit of what looks like easily duplicated > >> utility code. > >> > >> > > >> > All its other deps are present in WildFly Core. > >> > > >> > On 8/26/15 7:38 AM, Josef Cacek wrote: > >> >> Hi *, > >> >> > >> >> Is there a way how to configure Java security permissions in > >> >> WildFly Core? > >> >> If not, is there any reason why not to move the > >> >> wildfly-security-manager from WildFly into WildFly Core? > >> >> > >> >> I'm investigating failing tests in WildFly Core testsuite ([1],[2]) > >> >> when security manager is enabled. > >> >> > >> >> The problem is, security manager is in place and I'm not able to > >> >> define permissions for deployments > >> >> - using policy file (configured by java.security.policy system > >> >> property) doesn't work for me; > >> >> - putting META-INF/permissions.xml into deployments doesn't help > >> >> because PermissionsParseProcessor deployment processor is part of > >> >> wildfly-security-manager (i.e. not in Core) and it is only > >> >> activated when security-manager subsystem is present. > >> >> > >> >> So the tests fail because of AccessControlExceptions on the server > >> >> side. > >> >> > >> >> Any thoughts? > >> >> > >> >> As a workaround we can run the Core testsuite against full WildFly > >> >> and use either in-deployment permissions.xml or configure > >> >> permissions in subsystem [3] - but both ways have some > >> >> disadvantages. > >> >> We either have to put "unnecessary" permissions.xml in WFCORE > >> >> deployments or we have to use too wide minimum-permissions in > >> >> security-manager subsystem configuration. > >> >> > >> >> [1]https://issues.jboss.org/browse/WFCORE-846 > >> >> [2]https://issues.jboss.org/browse/JBEAP-526 > >> >> [3] > >> >> /subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions, > >> >> value=[{class=java.security.AllPermission}])") > >> >> > >> >> Thanks, > >> >> > >> >> -- Josef Cacek > >> >> _______________________________________________ > >> >> wildfly-dev mailing list > >> >>wildfly-dev at lists.jboss.org > >> >>https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> >> > >> > > >> > > >> > >> > >> -- > >> Brian Stansberry > >> Senior Principal Software Engineer > >> JBoss by Red Hat > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > _______________________________________________ > > 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 tomaz.cerar at gmail.com Fri Aug 28 06:19:55 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 28 Aug 2015 12:19:55 +0200 Subject: [wildfly-dev] Permissions in WildFly Core In-Reply-To: References: <532677388.10903538.1440592721682.JavaMail.zimbra@redhat.com> <55DDC3D4.1090909@redhat.com> <55DDC59C.5010205@redhat.com> Message-ID: If we could make it support jboss-permissions.xml without using jboss metadata that would solve the extra dependency and not much increase in distro size On Thu, Aug 27, 2015 at 1:08 PM, Jason T. Greene wrote: > That might actually be ok, since we aren't talking about a Java API, and > there are no reps on other specs. However I agree that is wierd. > Alternatively we could add different format/schema but I suspect it would > look just like permissions.xml. > > On Aug 26, 2015, at 9:00 AM, Toma? Cerar wrote: > > Also AFAIR, security manager subsystem implements EE7 security > manager(permissions.xml) support. > and as such doesn't belong to core. > > On Wed, Aug 26, 2015 at 3:56 PM, Brian Stansberry < > brian.stansberry at redhat.com> wrote: > >> On 8/26/15 8:49 AM, Brian Stansberry wrote: >> > Just some data, as I know distribution size is a significant factor in >> > deciding what goes into WildFly Core: >> > >> > The org.wildfly.extension.security.manager module itself is 45KB >> > unzipped, so not much of a concern. >> > >> > However, it depends on org.jboss.metadata.common, which is 475KB and >> > isn't itself present in WildFly Core. >> >> The requirement for org.jboss.metadata.common looks pretty simple to >> eliminate. It's just using a bit of what looks like easily duplicated >> utility code. >> >> > >> > All its other deps are present in WildFly Core. >> > >> > On 8/26/15 7:38 AM, Josef Cacek wrote: >> >> Hi *, >> >> >> >> Is there a way how to configure Java security permissions in WildFly >> Core? >> >> If not, is there any reason why not to move the >> wildfly-security-manager from WildFly into WildFly Core? >> >> >> >> I'm investigating failing tests in WildFly Core testsuite ([1],[2]) >> when security manager is enabled. >> >> >> >> The problem is, security manager is in place and I'm not able to >> define permissions for deployments >> >> - using policy file (configured by java.security.policy system >> property) doesn't work for me; >> >> - putting META-INF/permissions.xml into deployments doesn't help >> because PermissionsParseProcessor deployment processor is part of >> wildfly-security-manager (i.e. not in Core) and it is only activated when >> security-manager subsystem is present. >> >> >> >> So the tests fail because of AccessControlExceptions on the server >> side. >> >> >> >> Any thoughts? >> >> >> >> As a workaround we can run the Core testsuite against full WildFly and >> use either in-deployment permissions.xml or configure permissions in >> subsystem [3] - but both ways have some disadvantages. >> >> We either have to put "unnecessary" permissions.xml in WFCORE >> deployments or we have to use too wide minimum-permissions in >> security-manager subsystem configuration. >> >> >> >> [1] https://issues.jboss.org/browse/WFCORE-846 >> >> [2] https://issues.jboss.org/browse/JBEAP-526 >> >> [3] >> /subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions, >> value=[{class=java.security.AllPermission}])") >> >> >> >> Thanks, >> >> >> >> -- Josef Cacek >> >> _______________________________________________ >> >> wildfly-dev mailing list >> >> wildfly-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> > >> > >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150828/df71bbc9/attachment.html From brian.stansberry at redhat.com Fri Aug 28 09:38:01 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 28 Aug 2015 08:38:01 -0500 Subject: [wildfly-dev] Permissions in WildFly Core In-Reply-To: References: <532677388.10903538.1440592721682.JavaMail.zimbra@redhat.com> <55DDC3D4.1090909@redhat.com> <55DDC59C.5010205@redhat.com> Message-ID: <55E06439.8000104@redhat.com> Getting rid of the jboss metadata dependency is trivial. It just uses it for a no-op impl of a simple interface, and then a few one line utility methods to generate exception messages. On 8/28/15 5:19 AM, Toma? Cerar wrote: > If we could make it support jboss-permissions.xml without using jboss > metadata > that would solve the extra dependency and not much increase in distro size > > On Thu, Aug 27, 2015 at 1:08 PM, Jason T. Greene > > wrote: > > That might actually be ok, since we aren't talking about a Java API, > and there are no reps on other specs. However I agree that is wierd. > Alternatively we could add different format/schema but I suspect it > would look just like permissions.xml. > > On Aug 26, 2015, at 9:00 AM, Toma? Cerar > wrote: > >> Also AFAIR, security manager subsystem implements EE7 security >> manager(permissions.xml) support. >> and as such doesn't belong to core. >> >> On Wed, Aug 26, 2015 at 3:56 PM, Brian Stansberry >> > >> wrote: >> >> On 8/26/15 8:49 AM, Brian Stansberry wrote: >> > Just some data, as I know distribution size is a significant factor in >> > deciding what goes into WildFly Core: >> > >> > The org.wildfly.extension.security.manager module itself is 45KB >> > unzipped, so not much of a concern. >> > >> > However, it depends on org.jboss.metadata.common, which is 475KB and >> > isn't itself present in WildFly Core. >> >> The requirement for org.jboss.metadata.common looks pretty >> simple to >> eliminate. It's just using a bit of what looks like easily >> duplicated >> utility code. >> >> > >> > All its other deps are present in WildFly Core. >> > >> > On 8/26/15 7:38 AM, Josef Cacek wrote: >> >> Hi *, >> >> >> >> Is there a way how to configure Java security permissions >> in WildFly Core? >> >> If not, is there any reason why not to move the >> wildfly-security-manager from WildFly into WildFly Core? >> >> >> >> I'm investigating failing tests in WildFly Core testsuite >> ([1],[2]) when security manager is enabled. >> >> >> >> The problem is, security manager is in place and I'm not >> able to define permissions for deployments >> >> - using policy file (configured by java.security.policy >> system property) doesn't work for me; >> >> - putting META-INF/permissions.xml into deployments doesn't >> help because PermissionsParseProcessor deployment processor is >> part of wildfly-security-manager (i.e. not in Core) and it is >> only activated when security-manager subsystem is present. >> >> >> >> So the tests fail because of AccessControlExceptions on the >> server side. >> >> >> >> Any thoughts? >> >> >> >> As a workaround we can run the Core testsuite against full >> WildFly and use either in-deployment permissions.xml or >> configure permissions in subsystem [3] - but both ways have >> some disadvantages. >> >> We either have to put "unnecessary" permissions.xml in >> WFCORE deployments or we have to use too wide >> minimum-permissions in security-manager subsystem configuration. >> >> >> >> [1] https://issues.jboss.org/browse/WFCORE-846 >> >> [2] https://issues.jboss.org/browse/JBEAP-526 >> >> [3] >> /subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions, >> value=[{class=java.security.AllPermission}])") >> >> >> >> Thanks, >> >> >> >> -- Josef Cacek >> >> _______________________________________________ >> >> wildfly-dev mailing list >> >> wildfly-dev at lists.jboss.org >> >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> > >> > >> >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From rory.odonnell at oracle.com Fri Aug 28 12:47:24 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 28 Aug 2015 17:47:24 +0100 Subject: [wildfly-dev] Early Access builds for JDK 8u66 b02 and JDK 9 b78 are available on java.net Message-ID: <55E0909C.1020103@oracle.com> Hi Jason/Tomaz, Early Access build for JDK 8u66 b02 is available on java.net, summary of changes are listed here. Early Access build for JDK 9 b78 is available on java.net, summary of changes are listed here . With respect to ongoing JDK 9 development, I'd like to draw your attention to the following requests to provide feedback on the relevant mailing lists. *OpenJDK JarSigner API* JDK 9 is more restricted on calling sun.* public methods but we know there are users calling sun.security.tools.jarsigner.Main to sign jar files. A new API is proposed for this very purpose in OpenJDK. Feedback on this API should be provided on the security-dev mailing list. *RFC JEP: NIST SP 800-90A SecureRandom implementations : *Feedback on this draft JEP should be provided on the security-dev mailing list. * * *Public API for internal Swing classes* According to the JEP 200: The Modular JDK we expect that classes from internal packages (like sun.swing) will not be accessible. If you are using the internal Swing API and it is not possible to replace it by public API, please provide feedback on the swing-dev mailing list. If you haven?t already subscribed to a list then please do so first, otherwise your message will be discarded as spam. Finally, videos of presentations from the JVM Language Summit have been published at : http://www.oracle.com/technetwork/java/javase/community/jlssessions-2015-2633029.html . Rgds, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150828/d7f443d2/attachment-0001.html From tercio.carvalho at saint-gobain.com Fri Aug 28 13:02:49 2015 From: tercio.carvalho at saint-gobain.com (Carvalho, Tercio Spina) Date: Fri, 28 Aug 2015 17:02:49 +0000 Subject: [wildfly-dev] Wildfly 9.0.1 - Roadmap Message-ID: <8BB8D62FB0CF274D9ECF57E3A185C87768242A81@EXMB1NA12.zh.if.atcsg.net> Hi all Do you have any information about end-of-life or support of Wildfly 9.0.1? Regards. Tercio Spina. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150828/cfe71b74/attachment.html From tomaz.cerar at gmail.com Fri Aug 28 13:07:11 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 28 Aug 2015 19:07:11 +0200 Subject: [wildfly-dev] Early Access builds for JDK 8u66 b02 and JDK 9 b78 are available on java.net In-Reply-To: <55E0909C.1020103@oracle.com> References: <55E0909C.1020103@oracle.com> Message-ID: On Fri, Aug 28, 2015 at 6:47 PM, Rory O'Donnell wrote: > *OpenJDK JarSigner API* > JDK 9 is more restricted on calling sun.* public methods but we know there > are users calling > sun.security.tools.jarsigner.Main to sign jar files. A new API is proposed > > for > this very purpose in OpenJDK. > Feedback on this API should be provided on the security-dev > mailing list. We are users of this api in our testsuite, so this is a welcome change. Thank you info, Tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150828/f47e94d1/attachment.html From jorsol at gmail.com Fri Aug 28 13:38:46 2015 From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=) Date: Fri, 28 Aug 2015 11:38:46 -0600 Subject: [wildfly-dev] Wildfly 9.0.1 - Roadmap In-Reply-To: <8BB8D62FB0CF274D9ECF57E3A185C87768242A81@EXMB1NA12.zh.if.atcsg.net> References: <8BB8D62FB0CF274D9ECF57E3A185C87768242A81@EXMB1NA12.zh.if.atcsg.net> Message-ID: Hi Carvalho, WildFly is a community driven project and is moving fast, WildFly 10 is going to be released on October and AFAIK there is no formal support for a released version (ex.: 8.x) after the new version comes out (ex.: 9.x) there will be probably a few patches or backports to an earlier version but to stay really "supported" you must use the last available version. All WildFly versions (8.x, 9.x, 10.x) comply with the Java EE 7 specification, so if you stick to the standard then your app should run without problems in a later version. If you really need support or a formal end-of-life, then you must acquire a JBoss EAP subscription. For the moment there is only available JBoss EAP 6 wich comply with the Java EE 6 specification, but JBoss EAP 7 is on the works :-) Regards. Jorge Sol?rzano http://www.jorsol.com On Fri, Aug 28, 2015 at 11:02 AM, Carvalho, Tercio Spina wrote: > Hi all > > Do you have any information about end-of-life or support of Wildfly 9.0.1? > > > > Regards. > > > > Tercio Spina. > > > > > > > _______________________________________________ > 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 Aug 28 14:07:35 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 28 Aug 2015 19:07:35 +0100 Subject: [wildfly-dev] Early Access builds for JDK 8u66 b02 and JDK 9 b78 are available on java.net In-Reply-To: References: <55E0909C.1020103@oracle.com> Message-ID: <55E0A367.6090105@oracle.com> Hi Tomaz, Glad to hear it ! Rgds,Rory On 28/08/2015 18:07, Toma? Cerar wrote: > > On Fri, Aug 28, 2015 at 6:47 PM, Rory O'Donnell > > wrote: > > *OpenJDK JarSigner API* > JDK 9 is more restricted on calling sun.* public methods but we > know there are users calling > sun.security.tools.jarsigner.Main to sign jar files. A new API is > proposed > for > this very purpose in OpenJDK. > Feedback on this API should be provided on the security-dev > > mailing list. > > > > We are users of this api in our testsuite, so this is a welcome change. > > Thank you info, > Tomaz -- 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/20150828/68511b65/attachment.html From frank.langelage at osnanet.de Fri Aug 28 14:15:34 2015 From: frank.langelage at osnanet.de (Frank Langelage) Date: Fri, 28 Aug 2015 20:15:34 +0200 Subject: [wildfly-dev] "WildFly Test Suite: Integration - Web" fails completely since today In-Reply-To: <55DA451B.7030207@osnanet.de> References: <55DA2304.2080601@osnanet.de> <55DA451B.7030207@osnanet.de> Message-ID: <55E0A546.5010201@osnanet.de> The problem on Windows was, that port 9990 was occupied by a different process. The cause of the failure on Solaris seems to be not related by any update (directly). Yesterday I recognized that there are still some processes running for couple of days. Today I could reproduce it. build including smoke tests dailed with: Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.545 sec <<< FAILURE! - in org.jboss.as.test.integration.web.security.cert.WebSecurityCERTTestCase testClientCertUnsuccessfulAuth(org.jboss.as.test.integration.web.security.cert.WebSecurityCERTTestCase) Time elapsed: 0.04 sec <<< ERROR! java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:532) at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) at org.jboss.as.test.integration.web.security.cert.WebSecurityCERTTestCase.makeCall(WebSecurityCERTTestCase.java:152) at org.jboss.as.test.integration.web.security.cert.WebSecurityCERTTestCase.testClientCertUnsuccessfulAuth(WebSecurityCERTTestCase.java:144) testClientCertSuccessfulAuth(org.jboss.as.test.integration.web.security.cert.WebSecurityCERTTestCase) Time elapsed: 0.081 sec <<< ERROR! java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:532) at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:304) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) at org.jboss.as.test.integration.web.security.cert.WebSecurityCERTTestCase.makeCall(WebSecurityCERTTestCase.java:152) at org.jboss.as.test.integration.web.security.cert.WebSecurityCERTTestCase.testClientCertSuccessfulAuth(WebSecurityCERTTestCase.java:139) Running org.jboss.as.test.integration.web.security.external.WebSecurityExternalAuthTestCase Results : Tests in error: WebSecurityCERTTestCase.testClientCertUnsuccessfulAuth:144->makeCall:152 ? Connect WebSecurityCERTTestCase.testClientCertSuccessfulAuth:139->makeCall:152 ? Connect After "Running org.jboss.as.test.integration.web.security.external.WebSecurityExternalAuthTestCase" some minutes nothing happens, then the build process terminates with error message. But there are still runnning processes, a server instance and a client instance. UID PID PPID C STIME TTY TIME CMD jboss 24016 24015 0 18:44:39 pts/5 1:01 /export/home/mbi/tools/jdk/jdk1.8.0_60/jre/bin/java -Xmx512m -Djava.net.preferI jboss 24015 1 0 18:44:39 pts/5 0:00 /bin/sh -c cd /home/jboss/WildFly-10.0/wildfly/testsuite/integration/web/target jboss 24017 24016 0 18:44:51 pts/5 2:05 /mbi/tools/jdk/1.8.0/bin/java -D[Standalone] -Xms64m -Xmx512m -Xmx512m -Djava.n When I rerun the build with smoke tests, I then get errors like Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: JBOSS-LOCAL-USER: Server rejected authentication DIGEST-MD5: Server rejected authentication Tomaz, are there such processes on your Solaris 11 server too? Regards, Frank On 24.08.15 00:11, Frank Langelage wrote: > A build on Windows 7 using Java 1.8.0_60 shows similar problems for me. > > > On 23.08.15 22:57, Toma? Cerar wrote: >> >> Well good thing is that it can reproduced on our CI with Sparc >> Solaris 11 as well. >> >> More in depth analysis what why this happened, will need to wait till >> tomorow. >> >> -- >> tomaz >> >> On Sun, Aug 23, 2015 at 9:46 PM, Frank Langelage >> > wrote: >> >> After checkout of current Wildfly 10 CR1 sources the build with smoke >> tests fails. As of Friday everything was fine. >> >> Tests in error: >> DeploymentOverlayTestCase.org.jboss.as.test.integration.deployment.deploymentoverlay.DeploymentOverlayTestCase >> ? Deployment >> WarResourceListingTestCase.org.jboss.as.test.integration.deployment.resourcelisting.WarResourceListingTestCase >> ? Deployment >> WarClassLoadingTestCase.org.jboss.as.test.integration.deployment.classloading.war.WarClassLoadingTestCase >> ? Deployment >> WebModuleDeploymentTestCase.org.jboss.as.test.integration.web.annotationsmodule.WebModuleDeploymentTestCase >> ? Deployment >> CustomErrorsUnitTestCase.org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase >> ? Deployment >> FormAuthUnitTestCase.org.jboss.as.test.integration.web.formauth.FormAuthUnitTestCase >> ? Deployment >> UndertowHandlersConfigTestCase.org.jboss.as.test.integration.web.handlers.UndertowHandlersConfigTestCase >> ? Deployment >> RequestDumpingHandlerTestCase.org.jboss.as.test.integration.web.handlers.RequestDumpingHandlerTestCase >> ? Deployment >> ExternalTagLibTestCase.org.jboss.as.test.integration.web.jsp.taglib.external.ExternalTagLibTestCase >> ? Deployment >> JspMappingTestCase.org.jboss.as.test.integration.web.jsp.JspMappingTestCase >> ? Deployment >> JspSecurityManagerTestCase.org.jboss.as.test.integration.web.jsp.JspSecurityManagerTestCase >> ? Deployment >> DefaultServletMultipartConfigTestCase.org.jboss.as.test.integration.web.multipart.defaultservlet.DefaultServletMultipartConfigTestCase >> ? Deployment >> ReverseProxyTestCase.org.jboss.as.test.integration.web.reverseproxy.ReverseProxyTestCase >> ? Deployment >> ReverseProxyTestCase.tearDown:142 NullPointer >> RootContextWarUnitTestCase.org.jboss.as.test.integration.web.rootcontext.RootContextWarUnitTestCase >> ? Deployment >> RootContextEarUnitTestCase.org.jboss.as.test.integration.web.rootcontext.RootContextEarUnitTestCase >> ? Deployment >> WebSecurityBASICTestCase.org.jboss.as.test.integration.web.security.basic.WebSecurityBASICTestCase >> ? Deployment >> WebSecurityCERTTestCase.org.jboss.as.test.integration.web.security.cert.WebSecurityCERTTestCase >> ? Deployment >> WebSecurityExternalAuthTestCase.org.jboss.as.test.integration.web.security.external.WebSecurityExternalAuthTestCase >> ? Deployment >> WebSecurityJBossSimpleRoleMappingTestCase.org.jboss.as.test.integration.web.security.form.WebSecurityJBossSimpleRoleMappingTestCase >> ? Deployment >> WebSecurityFORMTestCase.org.jboss.as.test.integration.web.security.form.WebSecurityFORMTestCase >> ? Deployment >> WebSecurityProgrammaticLoginTestCase.org.jboss.as.test.integration.web.security.servlet3.WebSecurityProgrammaticLoginTestCase >> ? Deployment >> TransportGuaranteeTestCase.org.jboss.as.test.integration.web.security.tg.TransportGuaranteeTestCase >> ? Deployment >> ServletLifecycleMethodDescriptorTestCase.org.jboss.as.test.integration.web.servlet.lifecycle.ServletLifecycleMethodDescriptorTestCase >> ? Deployment >> EmptyCompEnvTestCase.org.jboss.as.test.integration.web.servlet.enc.empty.EmptyCompEnvTestCase >> ? Deployment >> ServletResourceOverlaysTestCase.org.jboss.as.test.integration.web.servlet.overlays.ServletResourceOverlaysTestCase >> ? Deployment >> SharedSessionTestCase.org.jboss.as.test.integration.web.sharedsession.SharedSessionTestCase >> ? Deployment >> ServletThreadPoolSelectionTestCase.org.jboss.as.test.integration.web.threads.ServletThreadPoolSelectionTestCase >> ? Deployment >> WebSocketTestCase.org.jboss.as.test.integration.web.websocket.WebSocketTestCase >> ? Deployment >> CookieUnitTestCase.org.jboss.as.test.integration.web.cookie.CookieUnitTestCase >> ? Deployment >> UndertowNonBlockingHandlerTestCase.org.jboss.as.test.integration.web.extension.UndertowNonBlockingHandlerTestCase >> ? Deployment >> DefaultConcurrencyServletTestCase.org.jboss.as.test.integration.ee.naming.defaultbindings.concurrency.DefaultConcurrencyServletTestCase >> ? Deployment >> DefaultContextServiceServletTestCase.org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase >> ? Deployment >> JspTagTestCase.org.jboss.as.test.integration.jsp.JspTagTestCase ? >> Deployment C... >> WarNotAsClientTest.org.jboss.as.test.smoke.web.WarNotAsClientTest ? >> Deployment >> WarTestCase.org.jboss.as.test.smoke.web.WarTestCase ? Deployment >> Cannot deploy... >> >> Tests run: 40, Failures: 0, Errors: 36, Skipped: 4 >> >> ... >> [INFO] WildFly: Servlet Distribution ...................... SUCCESS [ >> 10.220 s] >> [INFO] WildFly: Web Services Tests Integration Subsystem .. SUCCESS [ >> 8.569 s] >> [INFO] WildFly Test Suite: Shared ......................... SUCCESS [ >> 11.796 s] >> [INFO] WildFly Test Suite: Aggregator ..................... SUCCESS >> [02:18 min] >> [INFO] WildFly Test Suite: Integration .................... SUCCESS [ >> 7.957 s] >> [INFO] WildFly Test Suite: Integration - Web .............. FAILURE >> [01:07 min] >> [INFO] WildFly Test Suite: Integration - Smoke ............ SKIPPED >> >> The Caused by seems to be always the same: >> Caused by: javax.security.sasl.SaslException: Authentication >> failed: all >> available authentication mechanisms failed: >> JBOSS-LOCAL-USER: Server rejected authentication >> DIGEST-MD5: Server rejected authentication >> at >> org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114) >> at >> org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:393) >> at >> org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> at >> org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:198) >> at >> org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:112) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> at >> org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) >> 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:89) >> at org.xnio.nio.WorkerThread.run(WorkerThread.java:545) >> at ...asynchronous invocation...(Unknown Source) >> at >> org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) >> at >> org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) >> at >> org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) >> at >> org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) >> at >> org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:83) >> at >> org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:114) >> at >> org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257) >> at >> org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71) >> at >> org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:212) >> at >> org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146) >> at >> org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65) >> at >> org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147) >> at >> org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122) >> at >> org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) >> at >> org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) >> at >> org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeAsync(AbstractModelControllerClient.java:111) >> at >> org.jboss.as.controller.client.helpers.standalone.impl.ModelControllerClientServerDeploymentManager.executeOperation(ModelControllerClientServerDeploymentManager.java:50) >> at >> org.jboss.as.controller.client.helpers.standalone.impl.AbstractServerDeploymentManager.execute(AbstractServerDeploymentManager.java:79) >> at >> org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:54) >> at >> org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77) >> at >> org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64) >> at >> org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46) >> at >> org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144) >> at >> org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161) >> at >> org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128) >> at >> org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271) >> at >> org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127) >> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown >> Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:497) >> at >> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) >> at >> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) >> at >> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) >> at >> org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78) >> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown >> Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:497) >> at >> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) >> at >> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) >> at >> org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57) >> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown >> Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:497) >> at >> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) >> at >> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) >> at >> org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50) >> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown >> Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:497) >> at >> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) >> at >> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) >> at >> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) >> at >> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) >> at >> org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) >> at >> org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95) >> at >> org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80) >> at >> org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263) >> at >> org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239) >> at >> org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79) >> at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown >> Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:497) >> at >> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) >> at >> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) >> at >> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) >> at >> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) >> at >> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) >> at >> org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) >> at >> org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101) >> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown >> Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:497) >> at >> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) >> at >> org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) >> at >> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) >> at >> org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92) >> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown >> Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:497) >> at >> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) >> at >> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) >> at >> org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73) >> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown >> Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:497) >> at >> org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94) >> at >> org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) >> at >> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145) >> at >> org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116) >> at >> org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87) >> at >> org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201) >> at >> org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422) >> at >> org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) >> at >> org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218) >> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) >> at >> org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166) >> at org.junit.runners.Suite.runChild(Suite.java:127) >> at org.junit.runners.Suite.runChild(Suite.java:26) >> at >> org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) >> at >> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) >> at >> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) >> at >> org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) >> at >> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) >> at org.junit.runners.ParentRunner.run(ParentRunner.java:309) >> at org.junit.runner.JUnitCore.run(JUnitCore.java:160) >> at org.junit.runner.JUnitCore.run(JUnitCore.java:138) >> at >> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113) >> at >> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85) >> at >> org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54) >> at >> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134) >> at >> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200) >> at >> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) >> at >> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) >> >> Connecting to the server via jboss-cli.sh to run a script fails also: >> Failed to connect to the controller: Unable to authenticate against >> controller at localhost:9990: Authentication failed: all available >> authentication mechanisms failed: >> DIGEST-MD5: Server rejected authentication >> >> Platform is Oracle Solaris SPARC 10. >> >> java version "1.8.0_60" >> Java(TM) SE Runtime Environment (build 1.8.0_60-b27) >> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) >> >> _______________________________________________ >> 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/20150828/4c333fb5/attachment-0001.html From tercio.carvalho at saint-gobain.com Fri Aug 28 15:38:03 2015 From: tercio.carvalho at saint-gobain.com (Carvalho, Tercio Spina) Date: Fri, 28 Aug 2015 19:38:03 +0000 Subject: [wildfly-dev] RES: Wildfly 9.0.1 - Roadmap In-Reply-To: References: <8BB8D62FB0CF274D9ECF57E3A185C87768242A81@EXMB1NA12.zh.if.atcsg.net> Message-ID: <8BB8D62FB0CF274D9ECF57E3A185C87768243073@EXMB1NA12.zh.if.atcsg.net> Hello Sol?rzano, Thanks for you attention and information. Regards. Tercio Spina. -----Mensagem original----- De: Jorge Sol?rzano [mailto:jorsol at gmail.com] Enviada em: sexta-feira, 28 de agosto de 2015 14:39 Para: Carvalho, Tercio Spina Cc: wildfly-dev at lists.jboss.org Assunto: Re: [wildfly-dev] Wildfly 9.0.1 - Roadmap Hi Carvalho, WildFly is a community driven project and is moving fast, WildFly 10 is going to be released on October and AFAIK there is no formal support for a released version (ex.: 8.x) after the new version comes out (ex.: 9.x) there will be probably a few patches or backports to an earlier version but to stay really "supported" you must use the last available version. All WildFly versions (8.x, 9.x, 10.x) comply with the Java EE 7 specification, so if you stick to the standard then your app should run without problems in a later version. If you really need support or a formal end-of-life, then you must acquire a JBoss EAP subscription. For the moment there is only available JBoss EAP 6 wich comply with the Java EE 6 specification, but JBoss EAP 7 is on the works :-) Regards. Jorge Sol?rzano http://www.jorsol.com On Fri, Aug 28, 2015 at 11:02 AM, Carvalho, Tercio Spina wrote: > Hi all > > Do you have any information about end-of-life or support of Wildfly 9.0.1? > > > > Regards. > > > > Tercio Spina. > > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From ivangelarry at gmail.com Sat Aug 29 16:26:03 2015 From: ivangelarry at gmail.com (ivange larry) Date: Sat, 29 Aug 2015 21:26:03 +0100 Subject: [wildfly-dev] unable to join irc channel Message-ID: Hi all My name is Ivange Larry and am new to wildfly. I have tried to join #wildfly on irc using xchat with no success. When i run /join #wildfly, i get something like cannot join this channel, need to be identified with services. How can i fix this. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150829/deac41d7/attachment.html From tomaz.cerar at gmail.com Sat Aug 29 17:46:32 2015 From: tomaz.cerar at gmail.com (tomaz.cerar at gmail.com) Date: Sat, 29 Aug 2015 23:46:32 +0200 Subject: [wildfly-dev] unable to join irc channel In-Reply-To: References: Message-ID: <55e22838.4969b40a.7f201.ffffb765@mx.google.com> See https://freenode.net/faq.shtml#plusr Sent from my Phone -----Original Message----- From: "ivange larry" Sent: ?29.?8.?2015 22:26 To: "wildfly-dev at lists.jboss.org" Subject: [wildfly-dev] unable to join irc channel Hi all My name is Ivange Larry and am new to wildfly. I have tried to join #wildfly on irc using xchat with no success. When i run /join #wildfly, i get something like cannot join this channel, need to be identified with services. How can i fix this. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150829/b2200ffb/attachment.html From frank.langelage at osnanet.de Sun Aug 30 16:22:53 2015 From: frank.langelage at osnanet.de (Frank Langelage) Date: Sun, 30 Aug 2015 22:22:53 +0200 Subject: [wildfly-dev] Number of possible capabilities registered on resource and number of runtime capabilities don't match for path: ??? Message-ID: <55E3661D.7070402@osnanet.de> After todays upgrade to WildFly Core 2.0.0.Beta5 I see a couple of new warings: 22:19:23,926 INFO [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: WildFly Full 10.0.0.CR1-SNAPSHOT (WildFly Core 2.0.0.Beta5) starting 22:19:32,277 WARN [org.jboss.as.controller] (Controller Boot Thread) Number of possible capabilities registered on resource and number of runtime capabilities don't match for path: [("interface" => "management")] 22:19:32,284 WARN [org.jboss.as.controller] (Controller Boot Thread) Number of possible capabilities registered on resource and number of runtime capabilities don't match for path: [("interface" => "public")] 22:19:32,287 WARN [org.jboss.as.controller] (Controller Boot Thread) Number of possible capabilities registered on resource and number of runtime capabilities don't match for path: [("interface" => "unsecure")] 22:19:32,450 WARN [org.jboss.as.controller] (ServerService Thread Pool -- 26) Number of possible capabilities registered on resource and number of runtime capabilities don't match for path: [("subsystem" => "batch-jberet")] 22:19:32,454 WARN [org.jboss.as.controller] (ServerService Thread Pool -- 26) Number of possible capabilities registered on resource and number of runtime capabilities don't match for path: [ ("subsystem" => "batch-jberet"), ("in-memory-job-repository" => "in-memory") ] 22:19:32,501 WARN [org.jboss.as.controller] (ServerService Thread Pool -- 3) Number of possible capabilities registered on resource and number of runtime capabilities don't match for path: [("subsystem" => "jsr77")] 22:19:32,551 WARN [org.jboss.as.controller] (ServerService Thread Pool -- 18) Number of possible capabilities registered on resource and number of runtime capabilities don't match for path: [("subsystem" => "transactions")] 22:19:32,557 WARN [org.jboss.as.controller] (ServerService Thread Pool -- 8) Number of possible capabilities registered on resource and number of runtime capabilities don't match for path: [("subsystem" => "security")] 22:19:32,581 WARN [org.jboss.as.controller] (ServerService Thread Pool -- 13) Number of possible capabilities registered on resource and number of runtime capabilities don't match for path: [("subsystem" => "sar")] What's this? From tomaz.cerar at gmail.com Sun Aug 30 18:12:15 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 31 Aug 2015 00:12:15 +0200 Subject: [wildfly-dev] Number of possible capabilities registered on resource and number of runtime capabilities don't match for path: ??? In-Reply-To: <55E3661D.7070402@osnanet.de> References: <55E3661D.7070402@osnanet.de> Message-ID: Just warning for now, to let developers know to fix capability registration. This is part of ongoing process of moving to capabilities. https://issues.jboss.org/browse/WFCORE-912 is to remove the warning / properly register capabilities. also https://github.com/wildfly/wildfly/pull/7951 already addresses most of the warnings. -- tomaz On Sun, Aug 30, 2015 at 10:22 PM, Frank Langelage < frank.langelage at osnanet.de> wrote: > After todays upgrade to WildFly Core 2.0.0.Beta5 I see a couple of new > warings: > 22:19:23,926 INFO [org.jboss.as] (MSC service thread 1-4) WFLYSRV0049: > WildFly Full 10.0.0.CR1-SNAPSHOT (WildFly Core 2.0.0.Beta5) starting > 22:19:32,277 WARN [org.jboss.as.controller] (Controller Boot Thread) > Number of possible capabilities registered on resource and number of > runtime capabilities don't match for path: [("interface" => "management")] > 22:19:32,284 WARN [org.jboss.as.controller] (Controller Boot Thread) > Number of possible capabilities registered on resource and number of > runtime capabilities don't match for path: [("interface" => "public")] > 22:19:32,287 WARN [org.jboss.as.controller] (Controller Boot Thread) > Number of possible capabilities registered on resource and number of > runtime capabilities don't match for path: [("interface" => "unsecure")] > 22:19:32,450 WARN [org.jboss.as.controller] (ServerService Thread Pool > -- 26) Number of possible capabilities registered on resource and number > of runtime capabilities don't match for path: [("subsystem" => > "batch-jberet")] > 22:19:32,454 WARN [org.jboss.as.controller] (ServerService Thread Pool > -- 26) Number of possible capabilities registered on resource and number > of runtime capabilities don't match for path: [ > ("subsystem" => "batch-jberet"), > ("in-memory-job-repository" => "in-memory") > ] > 22:19:32,501 WARN [org.jboss.as.controller] (ServerService Thread Pool > -- 3) Number of possible capabilities registered on resource and number > of runtime capabilities don't match for path: [("subsystem" => "jsr77")] > 22:19:32,551 WARN [org.jboss.as.controller] (ServerService Thread Pool > -- 18) Number of possible capabilities registered on resource and number > of runtime capabilities don't match for path: [("subsystem" => > "transactions")] > 22:19:32,557 WARN [org.jboss.as.controller] (ServerService Thread Pool > -- 8) Number of possible capabilities registered on resource and number > of runtime capabilities don't match for path: [("subsystem" => "security")] > 22:19:32,581 WARN [org.jboss.as.controller] (ServerService Thread Pool > -- 13) Number of possible capabilities registered on resource and number > of runtime capabilities don't match for path: [("subsystem" => "sar")] > > What's this? > > _______________________________________________ > 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/20150831/d0e66556/attachment.html