From darran.lofthouse at jboss.com Fri Mar 3 06:36:59 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 3 Mar 2017 11:36:59 +0000 Subject: [wildfly-dev] Moving Elytron Subsystem into WildFly Core Message-ID: I am about to start the process of moving the WildFly Elytron Subsystem into WildFly Core. https://issues.jboss.org/browse/WFCORE-2352 For now I would suggest if you are working on changes to continue to submit PRs against the subsystem directly but be prepared that any that miss the cut off may need resubmitting against WildFly Core. Resubmission should not be a big task as the structure of the subsystem project should be largely unchanged. Regards, Darran Lofthouse. From rory.odonnell at oracle.com Fri Mar 3 07:22:46 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 3 Mar 2017 12:22:46 +0000 Subject: [wildfly-dev] JDK 9 EA Build 159 and JDK 8u152 is available on java.net Message-ID: <1bccb79a-134e-33fb-f784-2f9f6131df16@oracle.com> Hi Jason/Tomaz, *JDK 8u152 **Early Access b01 *is available on java.net *JDK 9 Early Access* b159 is available on java.net, summary of changes are listed here . There have been a number of fixes to bugs reported by Open Source projects since the last availability email : * b159 - JDK-8175261 : Per-protocol cache setting not working for JAR URLConnection * b158 - JDK-8173028 : Incorrect processing of supplementary-plane characters in text fields * b158 - JDK-8172967 : [macosx] Exception while working with layout for text containing unmappable character * b158 - JDK-8173804 : javadoc throws UnsupportedOperationException: should not happen * b157 - JDK-8174073 : NPE caused by @link reference to class * b156 - JDK-8172726 : ForkJoin common pool retains a reference to the thread context class loader The following changeset is included in jdk-9+158: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/8b0d55e02f54 If you have a user-defined Policy implementation that grants FilePermission on ${user.dir}/-, reading a file in the current directory using its base name will fail. Still the same solution: Ensure that the path used in permission granting has the same style as the one how you access the file. Setting -Djdk.security.filePermCompat=true will take you back to the jdk-9+140 behavior. Setting -Djdk.io.permissionsUseCanonicalPath=true will take you back to the jdk8 behavior. Feedback is welcome on jdk9-dev at openjdk.java.net Other areas of interest * JDK 9 Developer Guide [1] * JDK 9 Migration Guide [2] * JDK Cryptographic Roadmap [3] Finaly, Dalibor and I gave a presentation at FOSDEM the video is available here [*4*] Rgds,Rory [1] http://docs.oracle.com/javase/9/javase-docs.htm [2] https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899-4FB2-B34E-86D49B2E89B6 [3] https://www.java.com/en/jre-jdk-cryptoroadmap.html [4] https://fosdem.org/2017/schedule/event/outreach/ -- 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/20170303/a2541190/attachment-0001.html From jmesnil at redhat.com Fri Mar 3 12:10:32 2017 From: jmesnil at redhat.com (Jeff Mesnil) Date: Fri, 3 Mar 2017 18:10:32 +0100 Subject: [wildfly-dev] Prototype of Eclipse MicroProfile Config API in WildFly / Swarm Message-ID: <1CF524C0-E763-44CA-92B3-38BAD874C0E6@redhat.com> (I?m crossposting to wildfly-dev and widfly-swarm as both communities could be interested by this) TL;DR --- Out of curiosity, I?m working on a WildFly subsystem to expose the Eclipse MicroProfile Config API to applications deployed in WildFly and Swarm and I?m gauging interest for it. --- The Eclipse MicroProfile Config API[1] defines an API to access properties from various sources (OS, JVM, application, containers, etc.) using an uniform API. @Inject Config config ... String value = config.getString(?os.name?); The specification and API are in early stages but I?m considering supporting it in WildFly (and by extension in Swarm). I?ve written a prototype[2] that: * provides a basic Config implementation which reads properties from various sources: * OS / containers * JVM * application properties (backed by META-INF/microprofile-config.properties file in deployed application) * config-source resources (more on that below) * the Config API can be accessed using CDI or programmatically The implementation is very basic and buggy and I?m not sure if WildFly is the best place to provide an implementation (if we can integrate it from another project that provides it, that?d be fine). In any case, WildFly would support the Config API and expose it to deployed applications. I?ve added some fancy features to the WildFly subsystem to highlight a few use cases: * store properties directly in WildFly subsystem configuration * provide and HTTP access to config sources The WildFly subsystem can store directly properties that would be available for any deployed applications: This provides a centralized way to store properties accessed by different deployed applications. This also leverage WildFly management API to manage the properties (add/remove/update them). These config-sources can also be accessed using HTTP with a simple GET request: http://localhost:8080/wildfly-services/config-source// We could then imagine having clients on other nodes accessing these ?HTTP?-enabled config sources through the Config API. In a swarm of applications, this would allow to have some nodes serving as properties ?repository" and accessed by other nodes. I?ve written a companion example, a simple Web app, that uses CDI to access the Config API and lists all the properties from the various config sources.[3] The prototype I wrote is in very early stage (but already offers all the features above). The API and spec are also in very early stages and will likely change before they reaches 1.0. At this stage, before going any further, I?m interested to know: * who is interested by this Config API? * who is interested to *implement* this config API? * more specifically for WildFly and Swarm developers, is there already any other effort around this spec? cheers, jeff [1] https://github.com/microprofile/microprofile-config [2] https://github.com/jmesnil/microprofile-config-extension [3] https://github.com/jmesnil/microprofile-config-example/ -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From mazz at redhat.com Sat Mar 4 17:42:50 2017 From: mazz at redhat.com (John Mazzitelli) Date: Sat, 4 Mar 2017 17:42:50 -0500 (EST) Subject: [wildfly-dev] how a -javaagent can use logging and not blow up WildFly In-Reply-To: <1517520676.3338669.1488664515346.JavaMail.zimbra@redhat.com> Message-ID: <1580062279.3341230.1488667370205.JavaMail.zimbra@redhat.com> Regarding this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1037970 and the exception message: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager" How would one go about working around this when you have a -javaagent deployed in WildFly/EAP and that agent code actually uses logging? I've tried a bunch of stuff such as setting the sysprop java.util.logging.manager=org.jboss.logmanager.LogManager (both in standalone.conf and passing in via standalone.sh); in the agent code, first thing is call System.setProperty("java.util.logging.manager", "org.jboss.logmanager.LogManager"); I've tried getting the agent code to sleep and not even do any work until WildFly starts booting (though I'm not sure if some of my classes are getting loaded at the time premain() is called, but I can't see where its importing any logging stuff - unless its happening in low-level Java API code and setting java.util.logging itself?) There has to be a way to do this - I'm thinking of things like byteman which probably ran into the same thing. I'm hoping there is a simple "oh, you just do this magical step and it works around the problem." From brat000012001 at gmail.com Sun Mar 5 13:50:48 2017 From: brat000012001 at gmail.com (Peter Nalyvayko) Date: Sun, 5 Mar 2017 13:50:48 -0500 Subject: [wildfly-dev] Apache Portable Runtime (APR) in Wildfly Message-ID: Hello, Not sure if this is the right mailing list to post the question. Does Wildfly support Apache Portable Runtime? I've found some old discussions about configuring APR in JBoss Web/JBoss EAP that go a few years back, but nothing as far as Wildfly/APR support goes. A reference to a section in the documentation explicitly stating that such and such technology is not supported is really what I am after. Regards, --Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170305/35821e1c/attachment.html From tomaz.cerar at gmail.com Sun Mar 5 16:43:18 2017 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Sun, 5 Mar 2017 22:43:18 +0100 Subject: [wildfly-dev] how a -javaagent can use logging and not blow up WildFly In-Reply-To: <1580062279.3341230.1488667370205.JavaMail.zimbra@redhat.com> References: <1517520676.3338669.1488664515346.JavaMail.zimbra@redhat.com> <1580062279.3341230.1488667370205.JavaMail.zimbra@redhat.com> Message-ID: On Sat, Mar 4, 2017 at 11:42 PM, John Mazzitelli wrote: > "oh, you just do this magical step and it works around the problem." With recent builds setting system property org.wildfly.logging.skipLogManagerCheck=true should workaround your problem. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170305/417c437f/attachment.html From mazz at redhat.com Sun Mar 5 17:18:24 2017 From: mazz at redhat.com (John Mazzitelli) Date: Sun, 5 Mar 2017 17:18:24 -0500 (EST) Subject: [wildfly-dev] how a -javaagent can use logging and not blow up WildFly In-Reply-To: References: <1517520676.3338669.1488664515346.JavaMail.zimbra@redhat.com> <1580062279.3341230.1488667370205.JavaMail.zimbra@redhat.com> Message-ID: <1531140280.3379243.1488752304695.JavaMail.zimbra@redhat.com> > > "oh, you just do this magical step and it works around the problem." > > With recent builds setting system property org.wildfly.logging.skipLogManagerCheck=true > should workaround your problem. Ah.. That's a good one to know. I need something for earlier WildFly and EAP builds, though. But I recently found this solves my problem (this worked for me on both EAP6 and EAP7.1): Inside standalone.conf: # Add "org.jboss.logmanager" to the JBoss Modules system packages if [ "x$JBOSS_MODULES_SYSTEM_PKGS" = "x" ]; then JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman,org.jboss.logmanager" fi # Explicitly tell the VM to use the JBoss Log Manager via -Djava.util.logging.manager system property. # Use the -javaagent VM option to load the agent JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.jboss.logmanager.LogManager -javaagent:my-agent.jar" That seems to fix my problem. From stuart.w.douglas at gmail.com Sun Mar 5 19:48:13 2017 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Mon, 6 Mar 2017 11:48:13 +1100 Subject: [wildfly-dev] Apache Portable Runtime (APR) in Wildfly In-Reply-To: References: Message-ID: APR was required to use the native connectors in JBoss Web. It is not required when using Undertow. Stuart On Mon, Mar 6, 2017 at 5:50 AM, Peter Nalyvayko wrote: > Hello, > > Not sure if this is the right mailing list to post the question. Does > Wildfly support Apache Portable Runtime? I've found some old discussions > about configuring APR in JBoss Web/JBoss EAP that go a few years back, but > nothing as far as Wildfly/APR support goes. A reference to a section in > the documentation explicitly stating that such and such technology is not > supported is really what I am after. > > Regards, > --Peter > > _______________________________________________ > 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/20170306/52e5203b/attachment.html From darran.lofthouse at jboss.com Mon Mar 6 07:33:16 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 6 Mar 2017 12:33:16 +0000 Subject: [wildfly-dev] Latest WildFly Elytron Test Results - 2017-03-05 Message-ID: <2a79b79a-4e8e-8d75-d2e8-9b963fe3b578@jboss.com> Here are the latest test results after the most recent round of merges: - https://ci.wildfly.org/viewLog.html?buildId=48664&buildTypeId=WF_MasterNewInvocationTests&tab=buildResultsDiv We currently have 27 test failures, this is an increase on the last count but is also expected due to recent changes. These additional failures are in tests that were failing at the time of the original invocation merge and are not new tests. org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase.testNoTxEPCPropagation org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testNotAuthorizedClient org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testAuthorizedClient org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testNotAuthorizedClient org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testAuthorizedClient org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnlyBeforeCompletion org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationSucceeded org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnly org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationFailed org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException org.jboss.as.test.clustering.single.provider.ServiceProviderRegistrationTestCase.test org.jboss.as.test.clustering.single.dispatcher.CommandDispatcherTestCase.test org.jboss.as.test.clustering.single.registry.RegistryTestCase.test org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnlyBeforeCompletion org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationSucceeded org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances From sanne at hibernate.org Mon Mar 6 10:40:34 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Mon, 6 Mar 2017 15:40:34 +0000 Subject: [wildfly-dev] Apache Lucene modules for WildFly : evolution In-Reply-To: References: Message-ID: Hi all, I'm going to assume that there's no interest in giving these modules a "WildFly branding" and/or home, so I'll use the proposed org.hibernate.lucene-modules group id, and keep them on the Hibernate github organization. Last chance to propose alternatives this week ;) Thanks for any feedback! Sanne On 17 February 2017 at 12:00, Sanne Grinovero wrote: > # Context > > historically the Hibernate Search project released modules for > WildFly, so that people could use the latest version of it w/o having > to wait for WildFly to upgrade it and release. > > This zip we distribute would also include updated modules for Apache Lucene. > > We have now separated the Lucene modules into their own repository, so > that other projects (e.g. Infinispan) can use the same modules. > > In case you want to have a look, the POC is hosted at: > - https://github.com/hibernate/lucene-modules > > We planned to deploy this zip file as a Maven artifact under > coordinates "org.hibernate.lucene-modules:lucene-modules:lucene-modules". > > # I have three questions: > > ## Would it be useful to make this a "Feature Pack" ? > > Ideally we would like future versions of WildFly to use the same > structure (and same content) of these modules, when it will come to > upgrade the Lucene version within WildFly. > > That's because we will have already tested these in (at least) the > Hibernate and Infinispan projects, while replicating the same > structure within the WildFly build would not guarantee the same > output, and would not be covered by the same amount and quality of > integration tests. > > ## Would you prefer this to be hosted as github.com/wildfly ? > > We'd be happy to transfer ownership and still maintain it: having this > under "Hibernate" probably sends the wrong message. > It contains no Hibernate code and we'd like to encourage other people > possibly using Lucene on WildFly to use the same modules, again for > consistency reasons. > > ## Should we use a WildFly flavoured organization id? > > For the same reasons as in the previous question, yet I ask this > separately as I guess we could still keep it on github/hibernate if > you prefer, yet distribute it as "org.wildfly:lucene-modules" or > something else you might want to suggest. > > Thanks, > Sanne From mazz at redhat.com Mon Mar 6 10:51:23 2017 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 6 Mar 2017 10:51:23 -0500 (EST) Subject: [wildfly-dev] DMR -> JMX bridge ? In-Reply-To: <745287917.3777426.1488815323099.JavaMail.zimbra@redhat.com> Message-ID: <2105820710.3780596.1488815483046.JavaMail.zimbra@redhat.com> I was just informed that WildFly has a DMR -> JMX bridge, but I can't find anything on it. Is there such a thing or did I misunderstand? Particularly, is it true that for each DMR resource in the WildFly resource tree there is an associated JMX MBean with analogous JMX attributes/operations as you see in DMR? Can I do everything I want over JMX that I can do over the DMR management interface (I doubt deployments can be done over JMX, but maybe I'm wrong with that, too?) ??? I'm thinking I just misunderstand - wouldn't be the first time I was confused :) From anmiller at redhat.com Mon Mar 6 11:19:55 2017 From: anmiller at redhat.com (Andrig Miller) Date: Mon, 6 Mar 2017 09:19:55 -0700 Subject: [wildfly-dev] Apache Portable Runtime (APR) in Wildfly In-Reply-To: References: Message-ID: Also, we don't recommend using the native connections anymore. Since EAP 6.1, we have had an NIO2 based connector that is better than the native connector, and with EAP 7 we have Undertow (no need to have anything else). Andy On Sun, Mar 5, 2017 at 5:48 PM, Stuart Douglas wrote: > APR was required to use the native connectors in JBoss Web. It is not > required when using Undertow. > > Stuart > > On Mon, Mar 6, 2017 at 5:50 AM, Peter Nalyvayko > wrote: > >> Hello, >> >> Not sure if this is the right mailing list to post the question. Does >> Wildfly support Apache Portable Runtime? I've found some old discussions >> about configuring APR in JBoss Web/JBoss EAP that go a few years back, but >> nothing as far as Wildfly/APR support goes. A reference to a section in >> the documentation explicitly stating that such and such technology is not >> supported is really what I am after. >> >> Regards, >> --Peter >> >> _______________________________________________ >> 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 > -- Andrig (Andy) T. Miller Global Platform Director, Middleware Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170306/ed64d34b/attachment.html From brian.stansberry at redhat.com Mon Mar 6 11:28:53 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 6 Mar 2017 10:28:53 -0600 Subject: [wildfly-dev] Prototype of Eclipse MicroProfile Config API in WildFly / Swarm In-Reply-To: <1CF524C0-E763-44CA-92B3-38BAD874C0E6@redhat.com> References: <1CF524C0-E763-44CA-92B3-38BAD874C0E6@redhat.com> Message-ID: <09478A22-058D-4B86-B2E6-E1E8AF2811F4@redhat.com> Cool. :) Is the ?provide HTTP access to config sources? part of any proposed spec? ?Proposed spec? meaning discussion as a standard by the folks looking into Config API on the microprofile google group; i.e. not limited to some formal spec proposal. Either way we?ll need to give some thought to it. Since the start of AS7 we?ve sought to have a clean separation between ?management? and ?applications? and this is on the management side but AIUI is being exposed over the normal listener used for apps. There have been other requests along these lines (including a request from very early on to support management as a whole over 8080), and some of the barriers to doing that are coming down. For example in WF 12 elytron should let us support nice inflow of application layer user security identities into management. There have also been requests from the Infinispan folks to support custom contexts on the HTTP management interface. This could apply to that too if the endpoint was on 9090 not 8080. > On Mar 3, 2017, at 11:10 AM, Jeff Mesnil wrote: > > (I?m crossposting to wildfly-dev and widfly-swarm as both communities could be interested by this) > > TL;DR > --- > Out of curiosity, I?m working on a WildFly subsystem to expose the Eclipse MicroProfile Config API to applications deployed in WildFly and Swarm and I?m gauging interest for it. > --- > > The Eclipse MicroProfile Config API[1] defines an API to access properties from various sources (OS, JVM, application, containers, etc.) using an uniform API. > > @Inject > Config config > ... > String value = config.getString(?os.name?); > > The specification and API are in early stages but I?m considering supporting it in WildFly (and by extension in Swarm). > > I?ve written a prototype[2] that: > * provides a basic Config implementation which reads properties from various sources: > * OS / containers > * JVM > * application properties (backed by META-INF/microprofile-config.properties file in deployed application) > * config-source resources (more on that below) > * the Config API can be accessed using CDI or programmatically > > The implementation is very basic and buggy and I?m not sure if WildFly is the best place to provide an implementation (if we can integrate it from another project that provides it, that?d be fine). > In any case, WildFly would support the Config API and expose it to deployed applications. > > I?ve added some fancy features to the WildFly subsystem to highlight a few use cases: > * store properties directly in WildFly subsystem configuration > * provide and HTTP access to config sources > > The WildFly subsystem can store directly properties that would be available for any deployed applications: > > > > > > > > > > > This provides a centralized way to store properties accessed by different deployed applications. > This also leverage WildFly management API to manage the properties (add/remove/update them). > > These config-sources can also be accessed using HTTP with a simple GET request: > > http://localhost:8080/wildfly-services/config-source// > > We could then imagine having clients on other nodes accessing these ?HTTP?-enabled config sources through the Config API. > In a swarm of applications, this would allow to have some nodes serving as properties ?repository" and accessed by other nodes. > > I?ve written a companion example, a simple Web app, that uses CDI to access the Config API and lists all the properties from the various config sources.[3] > > The prototype I wrote is in very early stage (but already offers all the features above). > The API and spec are also in very early stages and will likely change before they reaches 1.0. > At this stage, before going any further, I?m interested to know: > > * who is interested by this Config API? > * who is interested to *implement* this config API? > * more specifically for WildFly and Swarm developers, is there already any other effort around this spec? > > cheers, > jeff > > [1] https://github.com/microprofile/microprofile-config > [2] https://github.com/jmesnil/microprofile-config-extension > [3] https://github.com/jmesnil/microprofile-config-example/ > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From ehugonne at redhat.com Mon Mar 6 11:46:15 2017 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Mon, 6 Mar 2017 17:46:15 +0100 Subject: [wildfly-dev] DMR -> JMX bridge ? In-Reply-To: <2105820710.3780596.1488815483046.JavaMail.zimbra@redhat.com> References: <2105820710.3780596.1488815483046.JavaMail.zimbra@redhat.com> Message-ID: <2c241ce5-5875-9bcc-126d-2701bf4712ed@redhat.com> Hi, This is done in the JMX subsystem with the ModelControllerMBeanServerPlugin. I'm not sure about limitations, but adding deployments should be possible. Emmanuel Le 06/03/2017 ? 16:51, John Mazzitelli a ?crit : > I was just informed that WildFly has a DMR -> JMX bridge, but I can't find anything on it. Is there such a thing or did I misunderstand? > > Particularly, is it true that for each DMR resource in the WildFly resource tree there is an associated JMX MBean with analogous JMX attributes/operations as you see in DMR? > > Can I do everything I want over JMX that I can do over the DMR management interface (I doubt deployments can be done over JMX, but maybe I'm wrong with that, too?) ??? > > I'm thinking I just misunderstand - wouldn't be the first time I was confused :) > _______________________________________________ > 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/20170306/f48945fd/attachment.bin From ehugonne at redhat.com Mon Mar 6 11:49:24 2017 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Mon, 6 Mar 2017 17:49:24 +0100 Subject: [wildfly-dev] how a -javaagent can use logging and not blow up WildFly In-Reply-To: <1531140280.3379243.1488752304695.JavaMail.zimbra@redhat.com> References: <1517520676.3338669.1488664515346.JavaMail.zimbra@redhat.com> <1580062279.3341230.1488667370205.JavaMail.zimbra@redhat.com> <1531140280.3379243.1488752304695.JavaMail.zimbra@redhat.com> Message-ID: <63ec3e33-0db5-e562-8517-8fbca8566d7a@redhat.com> Yes this works. This is how the NetBeans Profiler works around that :) Le 05/03/2017 ? 23:18, John Mazzitelli a ?crit : >>> "oh, you just do this magical step and it works around the problem." >> >> With recent builds setting system property org.wildfly.logging.skipLogManagerCheck=true >> should workaround your problem. > > Ah.. That's a good one to know. > > I need something for earlier WildFly and EAP builds, though. But I recently found this solves my problem (this worked for me on both EAP6 and EAP7.1): > > Inside standalone.conf: > > # Add "org.jboss.logmanager" to the JBoss Modules system packages > if [ "x$JBOSS_MODULES_SYSTEM_PKGS" = "x" ]; then > JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman,org.jboss.logmanager" > fi > > # Explicitly tell the VM to use the JBoss Log Manager via -Djava.util.logging.manager system property. > # Use the -javaagent VM option to load the agent > JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.jboss.logmanager.LogManager -javaagent:my-agent.jar" > > That seems to fix my problem. > _______________________________________________ > 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/20170306/9229b415/attachment-0001.bin From brian.stansberry at redhat.com Mon Mar 6 11:57:48 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 6 Mar 2017 10:57:48 -0600 Subject: [wildfly-dev] DMR -> JMX bridge ? In-Reply-To: <2105820710.3780596.1488815483046.JavaMail.zimbra@redhat.com> References: <2105820710.3780596.1488815483046.JavaMail.zimbra@redhat.com> Message-ID: The mbeans are exposed in the jboss.as and jboss.as.expr JMX domains. The latter resolves expressions; the former does not so lots of attributes are exposed a strings to account for the possibility of an expression. The view is read-only on a Host Controller process, including the master Domain Controller. There is no support for the composite operation. There is no support for request or response attachments. Request attachments are the standard way file uploads (e.g. deployments) to the server are done by non-raw-HTTP clients. (Raw HTTP clients like HAL use HTTP POST). Response attachments are used for the log-file viewer feature. No request headers are supported (e.g. rollback-on-runtime-failure, allow-resource-service-restart, blocking-timeout, rollout-plan, run-as). TBH I?ve forgotten how well we deal with complex attributes, but I suspect not very. > On Mar 6, 2017, at 9:51 AM, John Mazzitelli wrote: > > I was just informed that WildFly has a DMR -> JMX bridge, but I can't find anything on it. Is there such a thing or did I misunderstand? > > Particularly, is it true that for each DMR resource in the WildFly resource tree there is an associated JMX MBean with analogous JMX attributes/operations as you see in DMR? > > Can I do everything I want over JMX that I can do over the DMR management interface (I doubt deployments can be done over JMX, but maybe I'm wrong with that, too?) ??? > > I'm thinking I just misunderstand - wouldn't be the first time I was confused :) > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From jperkins at redhat.com Mon Mar 6 12:00:43 2017 From: jperkins at redhat.com (James Perkins) Date: Mon, 6 Mar 2017 09:00:43 -0800 Subject: [wildfly-dev] how a -javaagent can use logging and not blow up WildFly In-Reply-To: <1531140280.3379243.1488752304695.JavaMail.zimbra@redhat.com> References: <1517520676.3338669.1488664515346.JavaMail.zimbra@redhat.com> <1580062279.3341230.1488667370205.JavaMail.zimbra@redhat.com> <1531140280.3379243.1488752304695.JavaMail.zimbra@redhat.com> Message-ID: On Sun, Mar 5, 2017 at 2:18 PM, John Mazzitelli wrote: > > > "oh, you just do this magical step and it works around the problem." > > > > With recent builds setting system property org.wildfly.logging. > skipLogManagerCheck=true > > should workaround your problem. > > Ah.. That's a good one to know. > > I need something for earlier WildFly and EAP builds, though. But I > recently found this solves my problem (this worked for me on both EAP6 and > EAP7.1): > > Inside standalone.conf: > > # Add "org.jboss.logmanager" to the JBoss Modules system packages > if [ "x$JBOSS_MODULES_SYSTEM_PKGS" = "x" ]; then > JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman,org.jboss.logmanager" > fi > > # Explicitly tell the VM to use the JBoss Log Manager via > -Djava.util.logging.manager system property. > # Use the -javaagent VM option to load the agent > JAVA_OPTS="$JAVA_OPTS -Djava.util.logging.manager=org.jboss.logmanager.LogManager > -javaagent:my-agent.jar" > This is the correct solution. Skipping the check could potentially be an issue if the log manager installed is not the jboss-logmanager. Adding system module (or adding the library to the boot class path) and the java.util.logging.manager as the first system property in the JAVA_OPTS is the correct way to handle this. > > That seems to fix my problem. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170306/9830ddf9/attachment.html From brian.stansberry at redhat.com Mon Mar 6 12:08:22 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 6 Mar 2017 11:08:22 -0600 Subject: [wildfly-dev] DMR -> JMX bridge ? In-Reply-To: References: <2105820710.3780596.1488815483046.JavaMail.zimbra@redhat.com> Message-ID: <08C1A41E-B3F5-4001-A136-66A88AAF5DDC@redhat.com> > On Mar 6, 2017, at 10:57 AM, Brian Stansberry wrote: > > The mbeans are exposed in the jboss.as and jboss.as.expr JMX domains. The latter resolves expressions; the former does not so lots of attributes are exposed a strings to account for the possibility of an expression. > > The view is read-only on a Host Controller process, including the master Domain Controller. Also, proxying in a domain is not supported. You can see mbeans for resources local to the target process, but you can?t navigate to resources on other processes (i.e. from the DC to slave HCs or from an HC to its servers.) > > There is no support for the composite operation. > > There is no support for request or response attachments. Request attachments are the standard way file uploads (e.g. deployments) to the server are done by non-raw-HTTP clients. (Raw HTTP clients like HAL use HTTP POST). Response attachments are used for the log-file viewer feature. > > No request headers are supported (e.g. rollback-on-runtime-failure, allow-resource-service-restart, blocking-timeout, rollout-plan, run-as). > > TBH I?ve forgotten how well we deal with complex attributes, but I suspect not very. > > >> On Mar 6, 2017, at 9:51 AM, John Mazzitelli wrote: >> >> I was just informed that WildFly has a DMR -> JMX bridge, but I can't find anything on it. Is there such a thing or did I misunderstand? >> >> Particularly, is it true that for each DMR resource in the WildFly resource tree there is an associated JMX MBean with analogous JMX attributes/operations as you see in DMR? >> >> Can I do everything I want over JMX that I can do over the DMR management interface (I doubt deployments can be done over JMX, but maybe I'm wrong with that, too?) ??? >> >> I'm thinking I just misunderstand - wouldn't be the first time I was confused :) >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Brian Stansberry > Manager, 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 Manager, Senior Principal Software Engineer JBoss by Red Hat From hbraun at redhat.com Mon Mar 6 12:13:18 2017 From: hbraun at redhat.com (Heiko Braun) Date: Mon, 6 Mar 2017 18:13:18 +0100 Subject: [wildfly-dev] Prototype of Eclipse MicroProfile Config API in WildFly / Swarm In-Reply-To: <1CF524C0-E763-44CA-92B3-38BAD874C0E6@redhat.com> References: <1CF524C0-E763-44CA-92B3-38BAD874C0E6@redhat.com> Message-ID: > At this stage, before going any further, I?m interested to know: > > * who is interested by this Config API? > * who is interested to *implement* this config API? > * more specifically for WildFly and Swarm developers, is there already any other effort around this spec? > First of all, great work Jeff. It?s good to Wildfly devs picking up on Microprofile topics. With regard to your questions: Swarm certainly has an interest in implementing these API's and providing them to users. Actually we already have something in Swarm that resembles the microprofile ideas pretty closely and we thought of simply adapting the MP API to our implementation. But the ideas you outline here are interesting and a solution that provides mutual benefits to both Swarm and Wildfly is certainly our intention. I think we would need to find the common ground with respect to the actual implementation and based on that discuss a strategy to move forward. Do you think a conference call would be helpful bring everyone on the same page? Regards, Heiko From tomaz.cerar at gmail.com Mon Mar 6 12:29:03 2017 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 6 Mar 2017 18:29:03 +0100 Subject: [wildfly-dev] Apache Lucene modules for WildFly : evolution In-Reply-To: References: Message-ID: I think it is fine to have it in hibernate "branding" you could go for something like org.hibernate.wildfly:lucene-modules. This doesn't really belong in org.wildfly:lucence-modules. if anything it could be part of wildfly-extras and as such in org.wildfly.extras. But given that hibernate is well established project, no reason not to have it under its umbrella. -- tomaz On Mon, Mar 6, 2017 at 4:40 PM, Sanne Grinovero wrote: > Hi all, > > I'm going to assume that there's no interest in giving these modules a > "WildFly branding" and/or home, so I'll use the proposed > org.hibernate.lucene-modules group id, and keep them on the Hibernate > github organization. > > Last chance to propose alternatives this week ;) > > Thanks for any feedback! > > Sanne > > > On 17 February 2017 at 12:00, Sanne Grinovero wrote: > > # Context > > > > historically the Hibernate Search project released modules for > > WildFly, so that people could use the latest version of it w/o having > > to wait for WildFly to upgrade it and release. > > > > This zip we distribute would also include updated modules for Apache > Lucene. > > > > We have now separated the Lucene modules into their own repository, so > > that other projects (e.g. Infinispan) can use the same modules. > > > > In case you want to have a look, the POC is hosted at: > > - https://github.com/hibernate/lucene-modules > > > > We planned to deploy this zip file as a Maven artifact under > > coordinates "org.hibernate.lucene-modules:lucene-modules:lucene-modules" > . > > > > # I have three questions: > > > > ## Would it be useful to make this a "Feature Pack" ? > > > > Ideally we would like future versions of WildFly to use the same > > structure (and same content) of these modules, when it will come to > > upgrade the Lucene version within WildFly. > > > > That's because we will have already tested these in (at least) the > > Hibernate and Infinispan projects, while replicating the same > > structure within the WildFly build would not guarantee the same > > output, and would not be covered by the same amount and quality of > > integration tests. > > > > ## Would you prefer this to be hosted as github.com/wildfly ? > > > > We'd be happy to transfer ownership and still maintain it: having this > > under "Hibernate" probably sends the wrong message. > > It contains no Hibernate code and we'd like to encourage other people > > possibly using Lucene on WildFly to use the same modules, again for > > consistency reasons. > > > > ## Should we use a WildFly flavoured organization id? > > > > For the same reasons as in the previous question, yet I ask this > > separately as I guess we could still keep it on github/hibernate if > > you prefer, yet distribute it as "org.wildfly:lucene-modules" or > > something else you might want to suggest. > > > > Thanks, > > Sanne > _______________________________________________ > 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/20170306/a601efeb/attachment.html From smarlow at redhat.com Mon Mar 6 19:10:06 2017 From: smarlow at redhat.com (Scott Marlow) Date: Mon, 6 Mar 2017 19:10:06 -0500 Subject: [wildfly-dev] Latest WildFly Elytron Test Results - 2017-03-05 In-Reply-To: <2a79b79a-4e8e-8d75-d2e8-9b963fe3b578@jboss.com> References: <2a79b79a-4e8e-8d75-d2e8-9b963fe3b578@jboss.com> Message-ID: I couldn't reproduce the org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase failure locally, using wildfly master. Do I need to use the Elytron integration branches to recreate? On Mon, Mar 6, 2017 at 7:33 AM, Darran Lofthouse wrote: > Here are the latest test results after the most recent round of merges: - > > https://ci.wildfly.org/viewLog.html?buildId=48664&buildTypeId=WF_MasterNewInvocationTests&tab=buildResultsDiv > > We currently have 27 test failures, this is an increase on the last > count but is also expected due to recent changes. These additional > failures are in tests that were failing at the time of the original > invocation merge and are not new tests. > > org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase.testNoTxEPCPropagation > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testNotAuthorizedClient > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testAuthorizedClient > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testNotAuthorizedClient > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testAuthorizedClient > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnlyBeforeCompletion > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationSucceeded > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnly > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationFailed > org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful > org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException > org.jboss.as.test.clustering.single.provider.ServiceProviderRegistrationTestCase.test > org.jboss.as.test.clustering.single.dispatcher.CommandDispatcherTestCase.test > org.jboss.as.test.clustering.single.registry.RegistryTestCase.test > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnlyBeforeCompletion > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationSucceeded > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From tomaz.cerar at gmail.com Tue Mar 7 04:42:11 2017 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 7 Mar 2017 10:42:11 +0100 Subject: [wildfly-dev] Latest WildFly Elytron Test Results - 2017-03-05 In-Reply-To: References: <2a79b79a-4e8e-8d75-d2e8-9b963fe3b578@jboss.com> Message-ID: you need to run testsuite with -Dwildfly.tmp.enable.invocation.tests=true parameter. -- tomaz On Tue, Mar 7, 2017 at 1:10 AM, Scott Marlow wrote: > I couldn't reproduce the > org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase > failure locally, using wildfly master. Do I need to use the Elytron > integration branches to recreate? > > On Mon, Mar 6, 2017 at 7:33 AM, Darran Lofthouse > wrote: > > Here are the latest test results after the most recent round of merges: - > > > > https://ci.wildfly.org/viewLog.html?buildId=48664&buildTypeId=WF_ > MasterNewInvocationTests&tab=buildResultsDiv > > > > We currently have 27 test failures, this is an increase on the last > > count but is also expected due to recent changes. These additional > > failures are in tests that were failing at the time of the original > > invocation merge and are not new tests. > > > > org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase. > testNoTxEPCPropagation > > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase. > testDir > > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase. > testLdap > > org.jboss.as.test.integration.security.loginmodules. > RemotingLoginModuleTestCase.testNotAuthorizedClient > > org.jboss.as.test.integration.security.loginmodules. > RemotingLoginModuleTestCase.testAuthorizedClient > > org.jboss.as.test.integration.security.loginmodules. > RemotingLoginModuleUseNewClientCertTestCase.testNotAuthorizedClient > > org.jboss.as.test.integration.security.loginmodules. > RemotingLoginModuleUseNewClientCertTestCase.testAuthorizedClient > > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase. > testRollbackOnlyBeforeCompletion > > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase. > testSynchronizationSucceeded > > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestC > ase.testRollbackOnly > > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestC > ase.testSynchronizationFailed > > org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase. > timeoutStateful > > org.jboss.as.test.clustering.cluster.dispatcher. > CommandDispatcherTestCase(SYNC-tcp).test > > org.jboss.as.test.clustering.cluster.provider. > ServiceProviderRegistrationTestCase(SYNC-tcp).test > > org.jboss.as.test.clustering.cluster.registry. > RegistryTestCase(SYNC-tcp).test > > org.jboss.as.test.clustering.cluster.ejb.remote. > RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover > > org.jboss.as.test.clustering.cluster.ejb.remote. > RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover > > org.jboss.as.test.clustering.cluster.ejb.remote. > RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover > > org.jboss.as.test.clustering.cluster.ejb.remote. > RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover > > org.jboss.as.test.clustering.cluster.ejb.remote. > RemoteFailoverTestCase(SYNC-tcp).testClientException > > org.jboss.as.test.clustering.single.provider. > ServiceProviderRegistrationTestCase.test > > org.jboss.as.test.clustering.single.dispatcher. > CommandDispatcherTestCase.test > > org.jboss.as.test.clustering.single.registry.RegistryTestCase.test > > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase. > testRollbackOnlyBeforeCompletion > > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase. > testSynchronizationSucceeded > > org.jboss.as.test.multinode.remotecall.scoped.context. > DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation > > org.jboss.as.test.multinode.remotecall.scoped.context. > DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedE > JBProxyMemberInstances > > _______________________________________________ > > 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/20170307/4747ccf5/attachment.html From darran.lofthouse at jboss.com Tue Mar 7 05:44:17 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 7 Mar 2017 10:44:17 +0000 Subject: [wildfly-dev] Moving Elytron Subsystem into WildFly Core In-Reply-To: References: Message-ID: <3d41da11-a254-f87b-1fe7-027d8d537455@jboss.com> Brian has performed a preliminary review of the changes to add the subsystem to WildFly Core so I will be merging it to our incubator / ladybird branch later today. From this point no further pull requests will be merged to the independent subsystem project. For anyone with work in progress apart from one small code change to remove logging the subsystem's version the remaining code and project hierarchy is unmodified so it should be easy to port changes over. Regards, Darran Lofthouse. On 03/03/17 11:36, Darran Lofthouse wrote: > I am about to start the process of moving the WildFly Elytron Subsystem > into WildFly Core. > > https://issues.jboss.org/browse/WFCORE-2352 > > For now I would suggest if you are working on changes to continue to > submit PRs against the subsystem directly but be prepared that any that > miss the cut off may need resubmitting against WildFly Core. > > Resubmission should not be a big task as the structure of the subsystem > project should be largely unchanged. > > Regards, > Darran Lofthouse. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jmesnil at redhat.com Tue Mar 7 11:01:01 2017 From: jmesnil at redhat.com (Jeff Mesnil) Date: Tue, 7 Mar 2017 17:01:01 +0100 Subject: [wildfly-dev] Prototype of Eclipse MicroProfile Config API in WildFly / Swarm In-Reply-To: <09478A22-058D-4B86-B2E6-E1E8AF2811F4@redhat.com> References: <1CF524C0-E763-44CA-92B3-38BAD874C0E6@redhat.com> <09478A22-058D-4B86-B2E6-E1E8AF2811F4@redhat.com> Message-ID: > On 6 Mar 2017, at 17:28, Brian Stansberry wrote: > > Is the ?provide HTTP access to config sources? part of any proposed spec? ?Proposed spec? meaning discussion as a standard by the folks looking into Config API on the microprofile google group; i.e. not limited to some formal spec proposal. As far as I know, it?s not formally defined. The spec defines ?Custom ConfigSource?[1] that can load their properties from *somewhere*. The spec example reads it from a DB but I found the HTTP endpoint use case more compelling. > Either way we?ll need to give some thought to it. Since the start of AS7 we?ve sought to have a clean separation between ?management? and ?applications? and this is on the management side but AIUI is being exposed over the normal listener used for apps. There have been other requests along these lines (including a request from very early on to support management as a whole over 8080), and some of the barriers to doing that are coming down. For example in WF 12 elytron should let us support nice inflow of application layer user security identities into management. There have also been requests from the Infinispan folks to support custom contexts on the HTTP management interface. This could apply to that too if the endpoint was on 9090 not 8080. I should have provided more details about that. I definitely see that an ?application? service (on 8080) that are meant to be used by applications, not admins. My idea was to provide a *read-only* HTTP endpoint to read the properties from an application. However this HTTP API would not be able to manage the properties (adding/deleting/updating them). This would be provided by regular WildFly management API. [1] https://github.com/eclipse/microprofile-config/blob/master/spec/src/main/asciidoc/configsources.asciidoc#custom-configsources -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From brian.stansberry at redhat.com Tue Mar 7 11:12:31 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 7 Mar 2017 10:12:31 -0600 Subject: [wildfly-dev] Prototype of Eclipse MicroProfile Config API in WildFly / Swarm In-Reply-To: References: <1CF524C0-E763-44CA-92B3-38BAD874C0E6@redhat.com> <09478A22-058D-4B86-B2E6-E1E8AF2811F4@redhat.com> Message-ID: > On Mar 7, 2017, at 10:01 AM, Jeff Mesnil wrote: > > >> On 6 Mar 2017, at 17:28, Brian Stansberry wrote: >> >> Is the ?provide HTTP access to config sources? part of any proposed spec? ?Proposed spec? meaning discussion as a standard by the folks looking into Config API on the microprofile google group; i.e. not limited to some formal spec proposal. > > As far as I know, it?s not formally defined. > The spec defines ?Custom ConfigSource?[1] that can load their properties from *somewhere*. The spec example reads it from a DB but I found the HTTP endpoint use case more compelling. > >> Either way we?ll need to give some thought to it. Since the start of AS7 we?ve sought to have a clean separation between ?management? and ?applications? and this is on the management side but AIUI is being exposed over the normal listener used for apps. There have been other requests along these lines (including a request from very early on to support management as a whole over 8080), and some of the barriers to doing that are coming down. For example in WF 12 elytron should let us support nice inflow of application layer user security identities into management. There have also been requests from the Infinispan folks to support custom contexts on the HTTP management interface. This could apply to that too if the endpoint was on 9090 not 8080. > > I should have provided more details about that. > I definitely see that an ?application? service (on 8080) that are meant to be used by applications, not admins. > My idea was to provide a *read-only* HTTP endpoint to read the properties from an application. > However this HTTP API would not be able to manage the properties (adding/deleting/updating them). This would be provided by regular WildFly management API. > OK, got it. A server configured this way would act as a config source for other servers. That seems straightforward enough. > [1] https://github.com/eclipse/microprofile-config/blob/master/spec/src/main/asciidoc/configsources.asciidoc#custom-configsources > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From sstark at redhat.com Tue Mar 7 12:07:59 2017 From: sstark at redhat.com (Scott Stark) Date: Tue, 7 Mar 2017 12:07:59 -0500 (EST) Subject: [wildfly-dev] Prototype of Eclipse MicroProfile Config API in WildFly / Swarm In-Reply-To: References: <1CF524C0-E763-44CA-92B3-38BAD874C0E6@redhat.com> <09478A22-058D-4B86-B2E6-E1E8AF2811F4@redhat.com> Message-ID: <1316960688.28804274.1488906479550.JavaMail.zimbra@redhat.com> The management aspect will have to be defined in yet another layer, as is the monitoring aspect starting in this proposal. https://github.com/eclipse/microprofile-evolution-process/pull/12 Currently the notion of dynamic configuration values is not defined, so configuration/management/monitoring will overlap at some points as each area expands. ----- Original Message ----- From: "Brian Stansberry" To: "Jeff Mesnil" Cc: wildfly-swarm at googlegroups.com, "Gunnar Morling" , "WildFly Dev" Sent: Tuesday, March 7, 2017 8:12:31 AM Subject: Re: [wildfly-dev] Prototype of Eclipse MicroProfile Config API in WildFly / Swarm > On Mar 7, 2017, at 10:01 AM, Jeff Mesnil wrote: > > >> On 6 Mar 2017, at 17:28, Brian Stansberry wrote: >> >> Is the ?provide HTTP access to config sources? part of any proposed spec? ?Proposed spec? meaning discussion as a standard by the folks looking into Config API on the microprofile google group; i.e. not limited to some formal spec proposal. > > As far as I know, it?s not formally defined. > The spec defines ?Custom ConfigSource?[1] that can load their properties from *somewhere*. The spec example reads it from a DB but I found the HTTP endpoint use case more compelling. > >> Either way we?ll need to give some thought to it. Since the start of AS7 we?ve sought to have a clean separation between ?management? and ?applications? and this is on the management side but AIUI is being exposed over the normal listener used for apps. There have been other requests along these lines (including a request from very early on to support management as a whole over 8080), and some of the barriers to doing that are coming down. For example in WF 12 elytron should let us support nice inflow of application layer user security identities into management. There have also been requests from the Infinispan folks to support custom contexts on the HTTP management interface. This could apply to that too if the endpoint was on 9090 not 8080. > > I should have provided more details about that. > I definitely see that an ?application? service (on 8080) that are meant to be used by applications, not admins. > My idea was to provide a *read-only* HTTP endpoint to read the properties from an application. > However this HTTP API would not be able to manage the properties (adding/deleting/updating them). This would be provided by regular WildFly management API. > OK, got it. A server configured this way would act as a config source for other servers. That seems straightforward enough. > [1] https://github.com/eclipse/microprofile-config/blob/master/spec/src/main/asciidoc/configsources.asciidoc#custom-configsources > > -- > Jeff Mesnil > JBoss, a division of Red Hat > http://jmesnil.net/ > -- Brian Stansberry Manager, 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 smarlow at redhat.com Tue Mar 7 12:48:01 2017 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 7 Mar 2017 12:48:01 -0500 Subject: [wildfly-dev] Latest WildFly Elytron Test Results - 2017-03-05 In-Reply-To: References: <2a79b79a-4e8e-8d75-d2e8-9b963fe3b578@jboss.com> Message-ID: Thanks Tomaz, that helps me recreate it! It looks like the AssociationListener registered in org.jboss.as.txn.service.TransactionManagerService.start(StartContext) is calling registry.userTransactionStarted() when the passed transaction is not a user transaction (e.g. CMT). We should only call registry.userTransactionStarted() when there is an active user transaction (e.g. BMT). [1] shows the call stack. If I remove the call to registry.userTransactionStarted(), org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase passes. That is just a quick hack and not the right fix. Is there a way for TransactionManagerService to distinguish between BMT + CMT? Scott [1] https://paste.fedoraproject.org/paste/sdR0-0gPY4VqqSl34Iqhyl5M1UNdIGYhyRLivL9gydE= On Tue, Mar 7, 2017 at 4:42 AM, Toma? Cerar wrote: > you need to run testsuite with -Dwildfly.tmp.enable.invocation.tests=true > parameter. > > -- > tomaz > > On Tue, Mar 7, 2017 at 1:10 AM, Scott Marlow wrote: >> >> I couldn't reproduce the >> org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase >> failure locally, using wildfly master. Do I need to use the Elytron >> integration branches to recreate? >> >> On Mon, Mar 6, 2017 at 7:33 AM, Darran Lofthouse >> wrote: >> > Here are the latest test results after the most recent round of merges: >> > - >> > >> > >> > https://ci.wildfly.org/viewLog.html?buildId=48664&buildTypeId=WF_MasterNewInvocationTests&tab=buildResultsDiv >> > >> > We currently have 27 test failures, this is an increase on the last >> > count but is also expected due to recent changes. These additional >> > failures are in tests that were failing at the time of the original >> > invocation merge and are not new tests. >> > >> > >> > org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase.testNoTxEPCPropagation >> > >> > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir >> > >> > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap >> > >> > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testNotAuthorizedClient >> > >> > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testAuthorizedClient >> > >> > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testNotAuthorizedClient >> > >> > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testAuthorizedClient >> > >> > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnlyBeforeCompletion >> > >> > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationSucceeded >> > >> > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnly >> > >> > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationFailed >> > >> > org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful >> > >> > org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test >> > >> > org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test >> > >> > org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test >> > >> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover >> > >> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover >> > >> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover >> > >> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover >> > >> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException >> > >> > org.jboss.as.test.clustering.single.provider.ServiceProviderRegistrationTestCase.test >> > >> > org.jboss.as.test.clustering.single.dispatcher.CommandDispatcherTestCase.test >> > org.jboss.as.test.clustering.single.registry.RegistryTestCase.test >> > >> > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnlyBeforeCompletion >> > >> > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationSucceeded >> > >> > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation >> > >> > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From darran.lofthouse at jboss.com Tue Mar 7 13:20:26 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 7 Mar 2017 18:20:26 +0000 Subject: [wildfly-dev] Moving Elytron Subsystem into WildFly Core In-Reply-To: <3d41da11-a254-f87b-1fe7-027d8d537455@jboss.com> References: <3d41da11-a254-f87b-1fe7-027d8d537455@jboss.com> Message-ID: I have just merged the changes to our incubator. For now please submit any changes for the Elytron subsystem to the ladybird branch of our incubator repository: - https://github.com/wildfly-security-incubator/wildfly-core Regards, Darran Lofthouse. On 07/03/17 10:44, Darran Lofthouse wrote: > Brian has performed a preliminary review of the changes to add the > subsystem to WildFly Core so I will be merging it to our incubator / > ladybird branch later today. > > From this point no further pull requests will be merged to the > independent subsystem project. > > For anyone with work in progress apart from one small code change to > remove logging the subsystem's version the remaining code and project > hierarchy is unmodified so it should be easy to port changes over. > > Regards, > Darran Lofthouse. > > > On 03/03/17 11:36, Darran Lofthouse wrote: >> I am about to start the process of moving the WildFly Elytron Subsystem >> into WildFly Core. >> >> https://issues.jboss.org/browse/WFCORE-2352 >> >> For now I would suggest if you are working on changes to continue to >> submit PRs against the subsystem directly but be prepared that any that >> miss the cut off may need resubmitting against WildFly Core. >> >> Resubmission should not be a big task as the structure of the subsystem >> project should be largely unchanged. >> >> Regards, >> Darran Lofthouse. >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> From smarlow at redhat.com Tue Mar 7 13:55:04 2017 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 7 Mar 2017 13:55:04 -0500 Subject: [wildfly-dev] Latest WildFly Elytron Test Results - 2017-03-05 In-Reply-To: References: <2a79b79a-4e8e-8d75-d2e8-9b963fe3b578@jboss.com> Message-ID: I'll try checking if the passed transaction implements the UserTransaction interface and if yes, then call userTransactionStarted(). On Tue, Mar 7, 2017 at 12:48 PM, Scott Marlow wrote: > Thanks Tomaz, that helps me recreate it! > > It looks like the AssociationListener registered in > org.jboss.as.txn.service.TransactionManagerService.start(StartContext) > is calling registry.userTransactionStarted() when the passed > transaction is not a user transaction (e.g. CMT). We should only call > registry.userTransactionStarted() when there is an active user > transaction (e.g. BMT). [1] shows the call stack. > > If I remove the call to registry.userTransactionStarted(), > org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase > passes. That is just a quick hack and not the right fix. Is there a > way for TransactionManagerService to distinguish between BMT + CMT? > > Scott > > [1] https://paste.fedoraproject.org/paste/sdR0-0gPY4VqqSl34Iqhyl5M1UNdIGYhyRLivL9gydE= > > On Tue, Mar 7, 2017 at 4:42 AM, Toma? Cerar wrote: >> you need to run testsuite with -Dwildfly.tmp.enable.invocation.tests=true >> parameter. >> >> -- >> tomaz >> >> On Tue, Mar 7, 2017 at 1:10 AM, Scott Marlow wrote: >>> >>> I couldn't reproduce the >>> org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase >>> failure locally, using wildfly master. Do I need to use the Elytron >>> integration branches to recreate? >>> >>> On Mon, Mar 6, 2017 at 7:33 AM, Darran Lofthouse >>> wrote: >>> > Here are the latest test results after the most recent round of merges: >>> > - >>> > >>> > >>> > https://ci.wildfly.org/viewLog.html?buildId=48664&buildTypeId=WF_MasterNewInvocationTests&tab=buildResultsDiv >>> > >>> > We currently have 27 test failures, this is an increase on the last >>> > count but is also expected due to recent changes. These additional >>> > failures are in tests that were failing at the time of the original >>> > invocation merge and are not new tests. >>> > >>> > >>> > org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase.testNoTxEPCPropagation >>> > >>> > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir >>> > >>> > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap >>> > >>> > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testNotAuthorizedClient >>> > >>> > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testAuthorizedClient >>> > >>> > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testNotAuthorizedClient >>> > >>> > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testAuthorizedClient >>> > >>> > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnlyBeforeCompletion >>> > >>> > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationSucceeded >>> > >>> > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnly >>> > >>> > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationFailed >>> > >>> > org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful >>> > >>> > org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test >>> > >>> > org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test >>> > >>> > org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test >>> > >>> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover >>> > >>> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover >>> > >>> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover >>> > >>> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover >>> > >>> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException >>> > >>> > org.jboss.as.test.clustering.single.provider.ServiceProviderRegistrationTestCase.test >>> > >>> > org.jboss.as.test.clustering.single.dispatcher.CommandDispatcherTestCase.test >>> > org.jboss.as.test.clustering.single.registry.RegistryTestCase.test >>> > >>> > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnlyBeforeCompletion >>> > >>> > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationSucceeded >>> > >>> > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation >>> > >>> > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances >>> > _______________________________________________ >>> > wildfly-dev mailing list >>> > wildfly-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> From smarlow at redhat.com Tue Mar 7 21:43:14 2017 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 7 Mar 2017 21:43:14 -0500 Subject: [wildfly-dev] Latest WildFly Elytron Test Results - 2017-03-05 In-Reply-To: References: <2a79b79a-4e8e-8d75-d2e8-9b963fe3b578@jboss.com> Message-ID: org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase passes for me now, with David's fixes (https://github.com/dmlloyd/wildfly/commits/txn-client-creation + https://github.com/wildfly/wildfly-transaction-client)! On Tue, Mar 7, 2017 at 1:55 PM, Scott Marlow wrote: > I'll try checking if the passed transaction implements the > UserTransaction interface and if yes, then call > userTransactionStarted(). > > > > On Tue, Mar 7, 2017 at 12:48 PM, Scott Marlow wrote: >> Thanks Tomaz, that helps me recreate it! >> >> It looks like the AssociationListener registered in >> org.jboss.as.txn.service.TransactionManagerService.start(StartContext) >> is calling registry.userTransactionStarted() when the passed >> transaction is not a user transaction (e.g. CMT). We should only call >> registry.userTransactionStarted() when there is an active user >> transaction (e.g. BMT). [1] shows the call stack. >> >> If I remove the call to registry.userTransactionStarted(), >> org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase >> passes. That is just a quick hack and not the right fix. Is there a >> way for TransactionManagerService to distinguish between BMT + CMT? >> >> Scott >> >> [1] https://paste.fedoraproject.org/paste/sdR0-0gPY4VqqSl34Iqhyl5M1UNdIGYhyRLivL9gydE= >> >> On Tue, Mar 7, 2017 at 4:42 AM, Toma? Cerar wrote: >>> you need to run testsuite with -Dwildfly.tmp.enable.invocation.tests=true >>> parameter. >>> >>> -- >>> tomaz >>> >>> On Tue, Mar 7, 2017 at 1:10 AM, Scott Marlow wrote: >>>> >>>> I couldn't reproduce the >>>> org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase >>>> failure locally, using wildfly master. Do I need to use the Elytron >>>> integration branches to recreate? >>>> >>>> On Mon, Mar 6, 2017 at 7:33 AM, Darran Lofthouse >>>> wrote: >>>> > Here are the latest test results after the most recent round of merges: >>>> > - >>>> > >>>> > >>>> > https://ci.wildfly.org/viewLog.html?buildId=48664&buildTypeId=WF_MasterNewInvocationTests&tab=buildResultsDiv >>>> > >>>> > We currently have 27 test failures, this is an increase on the last >>>> > count but is also expected due to recent changes. These additional >>>> > failures are in tests that were failing at the time of the original >>>> > invocation merge and are not new tests. >>>> > >>>> > >>>> > org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase.testNoTxEPCPropagation >>>> > >>>> > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir >>>> > >>>> > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap >>>> > >>>> > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testNotAuthorizedClient >>>> > >>>> > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testAuthorizedClient >>>> > >>>> > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testNotAuthorizedClient >>>> > >>>> > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testAuthorizedClient >>>> > >>>> > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnlyBeforeCompletion >>>> > >>>> > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationSucceeded >>>> > >>>> > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnly >>>> > >>>> > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationFailed >>>> > >>>> > org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful >>>> > >>>> > org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test >>>> > >>>> > org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test >>>> > >>>> > org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test >>>> > >>>> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover >>>> > >>>> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover >>>> > >>>> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover >>>> > >>>> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover >>>> > >>>> > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException >>>> > >>>> > org.jboss.as.test.clustering.single.provider.ServiceProviderRegistrationTestCase.test >>>> > >>>> > org.jboss.as.test.clustering.single.dispatcher.CommandDispatcherTestCase.test >>>> > org.jboss.as.test.clustering.single.registry.RegistryTestCase.test >>>> > >>>> > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnlyBeforeCompletion >>>> > >>>> > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationSucceeded >>>> > >>>> > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation >>>> > >>>> > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances >>>> > _______________________________________________ >>>> > 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 brat000012001 at gmail.com Tue Mar 7 22:52:02 2017 From: brat000012001 at gmail.com (Peter Nalyvayko) Date: Tue, 7 Mar 2017 22:52:02 -0500 Subject: [wildfly-dev] Apache Portable Runtime (APR) in Wildfly In-Reply-To: References: Message-ID: Hi Andy, Thanks for clarifying. Is there off chance a document or a chart with performance metrics comparing NIO in Undertow vs native connectors with respect to SSL? Regards, Peter On Mon, Mar 6, 2017 at 11:19 AM, Andrig Miller wrote: > Also, we don't recommend using the native connections anymore. Since EAP > 6.1, we have had an NIO2 based connector that is better than the native > connector, and with EAP 7 we have Undertow (no need to have anything else). > > Andy > > On Sun, Mar 5, 2017 at 5:48 PM, Stuart Douglas > wrote: > >> APR was required to use the native connectors in JBoss Web. It is not >> required when using Undertow. >> >> Stuart >> >> On Mon, Mar 6, 2017 at 5:50 AM, Peter Nalyvayko >> wrote: >> >>> Hello, >>> >>> Not sure if this is the right mailing list to post the question. Does >>> Wildfly support Apache Portable Runtime? I've found some old discussions >>> about configuring APR in JBoss Web/JBoss EAP that go a few years back, but >>> nothing as far as Wildfly/APR support goes. A reference to a section in >>> the documentation explicitly stating that such and such technology is not >>> supported is really what I am after. >>> >>> Regards, >>> --Peter >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Andrig (Andy) T. Miller > Global Platform Director, Middleware > Red Hat, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170307/7d9304b5/attachment-0001.html From anmiller at redhat.com Wed Mar 8 11:19:49 2017 From: anmiller at redhat.com (Andrig Miller) Date: Wed, 8 Mar 2017 09:19:49 -0700 Subject: [wildfly-dev] Apache Portable Runtime (APR) in Wildfly In-Reply-To: References: Message-ID: On Tue, Mar 7, 2017 at 8:52 PM, Peter Nalyvayko wrote: > Hi Andy, > Thanks for clarifying. Is there off chance a document or a chart with > performance metrics comparing NIO in Undertow vs native connectors with > respect to SSL? > Regards, > Peter > ?In terms of Undertow and SSL, we have not done specific tests for that, but you don't have to use a native connector to get OpenSSL native code for SSL in Undertow, if my memory serves me correctly. Andy ? > > On Mon, Mar 6, 2017 at 11:19 AM, Andrig Miller > wrote: > >> Also, we don't recommend using the native connections anymore. Since EAP >> 6.1, we have had an NIO2 based connector that is better than the native >> connector, and with EAP 7 we have Undertow (no need to have anything else). >> >> Andy >> >> On Sun, Mar 5, 2017 at 5:48 PM, Stuart Douglas < >> stuart.w.douglas at gmail.com> wrote: >> >>> APR was required to use the native connectors in JBoss Web. It is not >>> required when using Undertow. >>> >>> Stuart >>> >>> On Mon, Mar 6, 2017 at 5:50 AM, Peter Nalyvayko >> > wrote: >>> >>>> Hello, >>>> >>>> Not sure if this is the right mailing list to post the question. Does >>>> Wildfly support Apache Portable Runtime? I've found some old discussions >>>> about configuring APR in JBoss Web/JBoss EAP that go a few years back, but >>>> nothing as far as Wildfly/APR support goes. A reference to a section in >>>> the documentation explicitly stating that such and such technology is not >>>> supported is really what I am after. >>>> >>>> Regards, >>>> --Peter >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Andrig (Andy) T. Miller >> Global Platform Director, Middleware >> Red Hat, Inc. >> > > -- Andrig (Andy) T. Miller Global Platform Director, Middleware Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170308/05a1b102/attachment.html From jason.greene at redhat.com Wed Mar 8 13:39:53 2017 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 8 Mar 2017 12:39:53 -0600 Subject: [wildfly-dev] Apache Portable Runtime (APR) in Wildfly In-Reply-To: References: Message-ID: <727CD589-4E28-4CE9-9250-4F93C06D2786@redhat.com> Right, even with SSL, the socket is managed using NIO. The difference is just that undertow utilizes the SSLEngine API, to provide the TLS crypto functionality. By default the SSLEngine impl utilized is the one provided by the JDK, but Undertow does allow for any alternative SSLEngine provider to be used instead. An example of one is the wildfly-openssl project which provides a generic SSLEngine implementation that delegates to your platform?s (or your custom) openssl library. This allows us to have a minimal native dependency chain, as well as consistent configuration values. > On Mar 8, 2017, at 10:19 AM, Andrig Miller wrote: > > > On Tue, Mar 7, 2017 at 8:52 PM, Peter Nalyvayko > wrote: > Hi Andy, > Thanks for clarifying. Is there off chance a document or a chart with performance metrics comparing NIO in Undertow vs native connectors with respect to SSL? > Regards, > Peter > > ?In terms of Undertow and SSL, we have not done specific tests for that, but you don't have to use a native connector to get OpenSSL native code for SSL in Undertow, if my memory serves me correctly. > > Andy > ? > > On Mon, Mar 6, 2017 at 11:19 AM, Andrig Miller > wrote: > Also, we don't recommend using the native connections anymore. Since EAP 6.1, we have had an NIO2 based connector that is better than the native connector, and with EAP 7 we have Undertow (no need to have anything else). > > Andy > > On Sun, Mar 5, 2017 at 5:48 PM, Stuart Douglas > wrote: > APR was required to use the native connectors in JBoss Web. It is not required when using Undertow. > > Stuart > > On Mon, Mar 6, 2017 at 5:50 AM, Peter Nalyvayko > wrote: > Hello, > > Not sure if this is the right mailing list to post the question. Does Wildfly support Apache Portable Runtime? I've found some old discussions about configuring APR in JBoss Web/JBoss EAP that go a few years back, but nothing as far as Wildfly/APR support goes. A reference to a section in the documentation explicitly stating that such and such technology is not supported is really what I am after. > > Regards, > --Peter > > _______________________________________________ > 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 > > > > -- > Andrig (Andy) T. Miller > Global Platform Director, Middleware > Red Hat, Inc. > > > > > -- > Andrig (Andy) T. Miller > Global Platform Director, Middleware > Red Hat, Inc. > _______________________________________________ > 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/20170308/0edd51e0/attachment.html From mazz at redhat.com Sat Mar 11 01:43:54 2017 From: mazz at redhat.com (John Mazzitelli) Date: Sat, 11 Mar 2017 01:43:54 -0500 (EST) Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> Message-ID: <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> OK, here's another one where I need some secret magical sauce - hoping someone knows of a technique I can use. Suppose I have a javaagent installed in a WildFly server (using the standard -javaagent VM argument). The javaagent would like to talk to the WildFly Server it is co-located with. Since it is in the same VM, the javaagent wants to avoid it looking like a remote call. But I know of no way to obtain a local ModelController instance to build a client short of injecting some service or subsystem into WildFly itself (something I would like to avoid). If the javaagent were instead a subsystem extension, it could do something like this: InjectedValue mcValue = new InjectedValue<>(); ... ((ServiceBuilder) bldr).addDependency(Services.JBOSS_SERVER_CONTROLLER, ModelController.class, mcValue); ... WHAT_I_WANT = mcValue.getValue().createClient(...) But obviously, that's no good for something running outside of the WildFly container (albeit in the same JVM). Any hope at all? I was thinking some trickery on the order of what ByteMan does in order to figure out a way to obtain a local ModelController? But that's a last ditch effort :) Hoping there is something that uses a little less witchcraft. From mazz at redhat.com Sun Mar 12 01:29:08 2017 From: mazz at redhat.com (John Mazzitelli) Date: Sun, 12 Mar 2017 01:29:08 -0500 (EST) Subject: [wildfly-dev] how not to pass a JVM arg from host controller to spawned servers? In-Reply-To: <688048478.3078253.1489299642375.JavaMail.zimbra@redhat.com> Message-ID: <240298730.3079513.1489300148315.JavaMail.zimbra@redhat.com> I noticed that whatever -D options you pass to the host controller (via HOST_CONTROLLER_JAVA_OPTS in domain.conf) by default also get passed along to all the servers that are spawned. If there is a specific system property that I do NOT want set in any spawned servers, how do I tell the host controller that? I simply just want to tell the host controller "The system properties named "abc" and "xyz" are *your* system properties only - they are not for any of the spawned servers to get. The other system properties you can pass down to the spawned servers." I'm hoping there is a way to do this without altering the host.xml definitions. From stuart.w.douglas at gmail.com Sun Mar 12 21:32:00 2017 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Mon, 13 Mar 2017 12:32:00 +1100 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> Message-ID: You can call org.jboss.as.server.CurrentServiceContainer#getServiceContainer() to do this, however it is trickey from a JavaAgent (as the module will not be available from the agent's class loader). Unfortunately there is no getting around this, as none of the API classes you need will be available in the module. As I see it you have a few different options: 1) Use reflection to get hold of this class, and then use reflection to make the calls 2) Create a class that does this directly, and then make sure it is loaded from the server module (which has access to the classes you need). There may be some other options, but that is all I can think of of the top of my head. If you want more info on how to implement either of these approaches feel free to ask me on hipchat. Stuart On Sat, Mar 11, 2017 at 5:43 PM, John Mazzitelli wrote: > OK, here's another one where I need some secret magical sauce - hoping > someone knows of a technique I can use. > > Suppose I have a javaagent installed in a WildFly server (using the > standard -javaagent VM argument). > > The javaagent would like to talk to the WildFly Server it is co-located > with. Since it is in the same VM, the javaagent wants to avoid it looking > like a remote call. > > But I know of no way to obtain a local ModelController instance to build a > client short of injecting some service or subsystem into WildFly itself > (something I would like to avoid). > > If the javaagent were instead a subsystem extension, it could do something > like this: > > InjectedValue mcValue = new InjectedValue<>(); > ... > ((ServiceBuilder) bldr).addDependency(Services.JBOSS_SERVER_CONTROLLER, > ModelController.class, mcValue); > ... > WHAT_I_WANT = mcValue.getValue().createClient(...) > > But obviously, that's no good for something running outside of the WildFly > container (albeit in the same JVM). > > Any hope at all? I was thinking some trickery on the order of what ByteMan > does in order to figure out a way to obtain a local ModelController? But > that's a last ditch effort :) Hoping there is something that uses a little > less witchcraft. > _______________________________________________ > 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/20170313/564ed23e/attachment-0001.html From ehugonne at redhat.com Mon Mar 13 05:04:54 2017 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Mon, 13 Mar 2017 10:04:54 +0100 Subject: [wildfly-dev] how not to pass a JVM arg from host controller to spawned servers? In-Reply-To: <240298730.3079513.1489300148315.JavaMail.zimbra@redhat.com> References: <240298730.3079513.1489300148315.JavaMail.zimbra@redhat.com> Message-ID: <5b92ec0a-3878-4563-88c7-b436f10757ef@redhat.com> Hi, This has been reported in https://issues.jboss.org/browse/WFCORE-350 and should be fixed in WildFly 11. Cheers, Emmanuel Le 12/03/2017 ? 07:29, John Mazzitelli a ?crit : > I noticed that whatever -D options you pass to the host controller (via HOST_CONTROLLER_JAVA_OPTS in domain.conf) by default also get passed along to all the servers that are spawned. If there is a specific system property that I do NOT want set in any spawned servers, how do I tell the host controller that? > > I simply just want to tell the host controller "The system properties named "abc" and "xyz" are *your* system properties only - they are not for any of the spawned servers to get. The other system properties you can pass down to the spawned servers." > > I'm hoping there is a way to do this without altering the host.xml definitions. > _______________________________________________ > 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/20170313/7f246112/attachment.bin From mazz at redhat.com Mon Mar 13 08:51:24 2017 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 13 Mar 2017 08:51:24 -0400 (EDT) Subject: [wildfly-dev] how not to pass a JVM arg from host controller to spawned servers? In-Reply-To: <5b92ec0a-3878-4563-88c7-b436f10757ef@redhat.com> References: <240298730.3079513.1489300148315.JavaMail.zimbra@redhat.com> <5b92ec0a-3878-4563-88c7-b436f10757ef@redhat.com> Message-ID: <1694360477.3633006.1489409484022.JavaMail.zimbra@redhat.com> > This has been reported in https://issues.jboss.org/browse/WFCORE-350 and > should be fixed in WildFly 11. Looks like this won't fix my specific problem. In the new code I see it only filters out certain sys props: https://github.com/wildfly/wildfly-core/pull/2082/files#diff-9f050a9a2a5d4653b0235563c6253102R79 But in my case, I'm passing in two sys props which aren't on the list, so it will still break. See my JIRA comment for my details: https://issues.jboss.org/browse/WFCORE-350?focusedCommentId=13376718&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13376718 > > Le 12/03/2017 ? 07:29, John Mazzitelli a ?crit : > > I noticed that whatever -D options you pass to the host controller (via > > HOST_CONTROLLER_JAVA_OPTS in domain.conf) by default also get passed along > > to all the servers that are spawned. If there is a specific system > > property that I do NOT want set in any spawned servers, how do I tell the > > host controller that? > > > > I simply just want to tell the host controller "The system properties named > > "abc" and "xyz" are *your* system properties only - they are not for any > > of the spawned servers to get. The other system properties you can pass > > down to the spawned servers." > > > > I'm hoping there is a way to do this without altering the host.xml > > definitions. > > _______________________________________________ > > 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 Mar 13 10:45:31 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 13 Mar 2017 09:45:31 -0500 Subject: [wildfly-dev] how not to pass a JVM arg from host controller to spawned servers? In-Reply-To: <240298730.3079513.1489300148315.JavaMail.zimbra@redhat.com> References: <240298730.3079513.1489300148315.JavaMail.zimbra@redhat.com> Message-ID: <0655704E-311F-4684-9C8C-C7510107244E@redhat.com> > On Mar 12, 2017, at 12:29 AM, John Mazzitelli wrote: > > I noticed that whatever -D options you pass to the host controller (via HOST_CONTROLLER_JAVA_OPTS in domain.conf) by default also get passed along to all the servers that are spawned. If there is a specific system property that I do NOT want set in any spawned servers, how do I tell the host controller that? > > I simply just want to tell the host controller "The system properties named "abc" and "xyz" are *your* system properties only - they are not for any of the spawned servers to get. The other system properties you can pass down to the spawned servers." > > I'm hoping there is a way to do this without altering the host.xml definitions. How important is this last bit? I guess pretty important as you want to instrument a process whose config you don?t control? > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Mon Mar 13 11:08:52 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 13 Mar 2017 10:08:52 -0500 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> Message-ID: <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> Once you get access to MSC, do not use Services.JBOSS_SERVER_CONTROLLER to get a ModelController to create the client. That method is deprecated and I plan to remove it in the next release (WildFly Core 4 / WildFly 12). Use ServiceName.parse("org.wildfly.managment.model-controller-client-factory?) to get a ModelControllerClientFactory and use it to create a client, calling createSuperUserClient. Note that if you want that client to work properly in a SecurityManager enabled environment your code will need to have org.jboss.as.controller.security.ControllerPermission#PERFORM_IN_VM_CALL PERFORM_IN_VM_CALL. The security guys added in that requirement for WF Core 3. Note that applies even if you use the deprecated ModelController.createClient method. > On Mar 12, 2017, at 8:32 PM, Stuart Douglas wrote: > > You can call org.jboss.as.server.CurrentServiceContainer#getServiceContainer() to do this, however it is trickey from a JavaAgent (as the module will not be available from the agent's class loader). > > Unfortunately there is no getting around this, as none of the API classes you need will be available in the module. As I see it you have a few different options: > > 1) Use reflection to get hold of this class, and then use reflection to make the calls > 2) Create a class that does this directly, and then make sure it is loaded from the server module (which has access to the classes you need). > > There may be some other options, but that is all I can think of of the top of my head. > > If you want more info on how to implement either of these approaches feel free to ask me on hipchat. > > Stuart > > On Sat, Mar 11, 2017 at 5:43 PM, John Mazzitelli wrote: > OK, here's another one where I need some secret magical sauce - hoping someone knows of a technique I can use. > > Suppose I have a javaagent installed in a WildFly server (using the standard -javaagent VM argument). > > The javaagent would like to talk to the WildFly Server it is co-located with. Since it is in the same VM, the javaagent wants to avoid it looking like a remote call. > > But I know of no way to obtain a local ModelController instance to build a client short of injecting some service or subsystem into WildFly itself (something I would like to avoid). > > If the javaagent were instead a subsystem extension, it could do something like this: > > InjectedValue mcValue = new InjectedValue<>(); > ... > ((ServiceBuilder) bldr).addDependency(Services.JBOSS_SERVER_CONTROLLER, ModelController.class, mcValue); > ... > WHAT_I_WANT = mcValue.getValue().createClient(...) > > But obviously, that's no good for something running outside of the WildFly container (albeit in the same JVM). > > Any hope at all? I was thinking some trickery on the order of what ByteMan does in order to figure out a way to obtain a local ModelController? But that's a last ditch effort :) Hoping there is something that uses a little less witchcraft. > _______________________________________________ > 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 Manager, Senior Principal Software Engineer JBoss by Red Hat From jason.greene at redhat.com Mon Mar 13 11:29:25 2017 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 13 Mar 2017 10:29:25 -0500 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> Message-ID: Hi John, Before moving with non-traditional access like this I think we need to make sure the overall strategy behind what you are building is something we can support over multiple releases. Of course, a lot of that depends on your compatibility expectations. > On Mar 13, 2017, at 10:08 AM, Brian Stansberry wrote: > > Once you get access to MSC, do not use Services.JBOSS_SERVER_CONTROLLER to get a ModelController to create the client. That method is deprecated and I plan to remove it in the next release (WildFly Core 4 / WildFly 12). > > Use ServiceName.parse("org.wildfly.managment.model-controller-client-factory?) to get a ModelControllerClientFactory and use it to create a client, calling createSuperUserClient. > > Note that if you want that client to work properly in a SecurityManager enabled environment your code will need to have org.jboss.as.controller.security.ControllerPermission#PERFORM_IN_VM_CALL PERFORM_IN_VM_CALL. The security guys added in that requirement for WF Core 3. Note that applies even if you use the deprecated ModelController.createClient method. > >> On Mar 12, 2017, at 8:32 PM, Stuart Douglas wrote: >> >> You can call org.jboss.as.server.CurrentServiceContainer#getServiceContainer() to do this, however it is trickey from a JavaAgent (as the module will not be available from the agent's class loader). >> >> Unfortunately there is no getting around this, as none of the API classes you need will be available in the module. As I see it you have a few different options: >> >> 1) Use reflection to get hold of this class, and then use reflection to make the calls >> 2) Create a class that does this directly, and then make sure it is loaded from the server module (which has access to the classes you need). >> >> There may be some other options, but that is all I can think of of the top of my head. >> >> If you want more info on how to implement either of these approaches feel free to ask me on hipchat. >> >> Stuart >> >> On Sat, Mar 11, 2017 at 5:43 PM, John Mazzitelli wrote: >> OK, here's another one where I need some secret magical sauce - hoping someone knows of a technique I can use. >> >> Suppose I have a javaagent installed in a WildFly server (using the standard -javaagent VM argument). >> >> The javaagent would like to talk to the WildFly Server it is co-located with. Since it is in the same VM, the javaagent wants to avoid it looking like a remote call. >> >> But I know of no way to obtain a local ModelController instance to build a client short of injecting some service or subsystem into WildFly itself (something I would like to avoid). >> >> If the javaagent were instead a subsystem extension, it could do something like this: >> >> InjectedValue mcValue = new InjectedValue<>(); >> ... >> ((ServiceBuilder) bldr).addDependency(Services.JBOSS_SERVER_CONTROLLER, ModelController.class, mcValue); >> ... >> WHAT_I_WANT = mcValue.getValue().createClient(...) >> >> But obviously, that's no good for something running outside of the WildFly container (albeit in the same JVM). >> >> Any hope at all? I was thinking some trickery on the order of what ByteMan does in order to figure out a way to obtain a local ModelController? But that's a last ditch effort :) Hoping there is something that uses a little less witchcraft. >> _______________________________________________ >> 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 > Manager, Senior Principal Software Engineer > JBoss by Red Hat > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From mazz at redhat.com Mon Mar 13 12:28:13 2017 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 13 Mar 2017 12:28:13 -0400 (EDT) Subject: [wildfly-dev] how not to pass a JVM arg from host controller to spawned servers? In-Reply-To: <0655704E-311F-4684-9C8C-C7510107244E@redhat.com> References: <240298730.3079513.1489300148315.JavaMail.zimbra@redhat.com> <0655704E-311F-4684-9C8C-C7510107244E@redhat.com> Message-ID: <1040688653.4102980.1489422493966.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > > On Mar 12, 2017, at 12:29 AM, John Mazzitelli wrote: > > > > I noticed that whatever -D options you pass to the host controller (via > > HOST_CONTROLLER_JAVA_OPTS in domain.conf) by default also get passed along > > to all the servers that are spawned. If there is a specific system > > property that I do NOT want set in any spawned servers, how do I tell the > > host controller that? > > > > I simply just want to tell the host controller "The system properties named > > "abc" and "xyz" are *your* system properties only - they are not for any > > of the spawned servers to get. The other system properties you can pass > > down to the spawned servers." > > > > I'm hoping there is a way to do this without altering the host.xml > > definitions. > > How important is this last bit? > > I guess pretty important as you want to instrument a process whose config you > don?t control? Right, that's the idea. Affect as little config as possible. From mazz at redhat.com Mon Mar 13 13:19:32 2017 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 13 Mar 2017 13:19:32 -0400 (EDT) Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> Message-ID: <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> OK, here's the basic gist of what this is for - I'll try to keep it short. WHAT THE AGENT DOES: The "Hawkular WildFly Agent" looks at the tree of resources in its monitored servers (e.g. for WildFly servers, things like "/subsystem=datasources/data-source=MyH2" are resources; for JMX MBeanServers, MBeans are resources), and collects metrics from those resources. It stores that inventory and metric data to a backend Hawkular Server. Systems like ManageIQ, CloudForms, and even things like Grafana can then display in their UIs the inventory details (e.g. "here's a list of your 5 EAP servers"), and pretty graphs of all their metrics (e.g. "here's what your 5 EAP servers' heap memory usages look like"). HOW THE AGENT RUNS TODAY: Today, Hawkular WildFly Agent MUST BE installed as a subsystem. It can be installed in EAP 6.4, EAP 7.0/7.1, and their associated WildFly versions - but it has to be hosted in one of those things because it is implemented as a subsystem extension. It can be installed in a standalone server or a host controller. It can collect inventory and metric data for the server it is running in. WHY WE WANT TO CHANGE: But we have received feedback that "it would be nice to support this agent in a bunch of other projects that are not EAP based." Think Karaf-based or vert-x based applications that expose inventory/metrics over JMX. We want to collect inventory and metrics from non-EAP-based products that expose JMX so ManageIQ and CloudForms can see them just like EAP-based projects can be seen today. So I refactored the Hawkular Agent core engine so it can run EITHER as a subsystem extension OR as a VM java agent. Then I have received feedback, "it would be nice to not have to support and maintain both versions of the agent - just support the Java Agent since it can monitor EAP and non-EAP based products. Throw away the subsystem one since it isn't needed anymore." WHAT IS THE PROBLEM? Right now, I have a java agent that is working well and can support both EAP and non-EAP based products. However, there are two problems: 1) Unrelated to this email thread, but I can't run this java agent in a Host controller (that's this JIRA: https://issues.jboss.org/browse/WFCORE-2526) - the workaround for this is to run the agent in its own JVM and remotely monitor the Host Controller. Not ideal because now it has to go through the remote management endpoint. Other workaround is to rip out jboss logging entirely from my agent and use some other logging framework. But again, ignore that for now. Not relevant to this discussion. 2) Even though the agent is running co-located inside the WildFly JVM as a javaagent, it can't get a local client so it can talk locally to it. It must go through the remote management endpoint. I would like this agent to get a local ModelController so it can build clients like it can today when running in a subsystem. The agent (when running as a subsystem) uses code similar to this: InjectedValue mcValue = new InjectedValue<>(); ... ((ServiceBuilder) bldr).addDependency(Services.JBOSS_SERVER_CONTROLLER, ModelController.class, mcValue); ... WHAT_I_WANT = mcValue.getValue().createClient(...) I need something similar in the javaagent - I need to get that local ModelController so the javaagent can build a local client and thus avoid having to configure the WildFly remote management interface and avoid having to make remote calls to its co-located WildFly Server. Hopefully, that makes sense. Sorry - wasn't short :) ----- Original Message ----- > Hi John, > > Before moving with non-traditional access like this I think we need to make > sure the overall strategy behind what you are building is something we can > support over multiple releases. Of course, a lot of that depends on your > compatibility expectations. > > > On Mar 13, 2017, at 10:08 AM, Brian Stansberry > > wrote: > > > > Once you get access to MSC, do not use Services.JBOSS_SERVER_CONTROLLER to > > get a ModelController to create the client. That method is deprecated and > > I plan to remove it in the next release (WildFly Core 4 / WildFly 12). > > > > Use > > ServiceName.parse("org.wildfly.managment.model-controller-client-factory?) > > to get a ModelControllerClientFactory and use it to create a client, > > calling createSuperUserClient. > > > > Note that if you want that client to work properly in a SecurityManager > > enabled environment your code will need to have > > org.jboss.as.controller.security.ControllerPermission#PERFORM_IN_VM_CALL > > PERFORM_IN_VM_CALL. The security guys added in that requirement for WF > > Core 3. Note that applies even if you use the deprecated > > ModelController.createClient method. > > > >> On Mar 12, 2017, at 8:32 PM, Stuart Douglas > >> wrote: > >> > >> You can call > >> org.jboss.as.server.CurrentServiceContainer#getServiceContainer() to do > >> this, however it is trickey from a JavaAgent (as the module will not be > >> available from the agent's class loader). > >> > >> Unfortunately there is no getting around this, as none of the API classes > >> you need will be available in the module. As I see it you have a few > >> different options: > >> > >> 1) Use reflection to get hold of this class, and then use reflection to > >> make the calls > >> 2) Create a class that does this directly, and then make sure it is loaded > >> from the server module (which has access to the classes you need). > >> > >> There may be some other options, but that is all I can think of of the top > >> of my head. > >> > >> If you want more info on how to implement either of these approaches feel > >> free to ask me on hipchat. > >> > >> Stuart > >> > >> On Sat, Mar 11, 2017 at 5:43 PM, John Mazzitelli wrote: > >> OK, here's another one where I need some secret magical sauce - hoping > >> someone knows of a technique I can use. > >> > >> Suppose I have a javaagent installed in a WildFly server (using the > >> standard -javaagent VM argument). > >> > >> The javaagent would like to talk to the WildFly Server it is co-located > >> with. Since it is in the same VM, the javaagent wants to avoid it looking > >> like a remote call. > >> > >> But I know of no way to obtain a local ModelController instance to build a > >> client short of injecting some service or subsystem into WildFly itself > >> (something I would like to avoid). > >> > >> If the javaagent were instead a subsystem extension, it could do something > >> like this: > >> > >> InjectedValue mcValue = new InjectedValue<>(); > >> ... > >> ((ServiceBuilder) bldr).addDependency(Services.JBOSS_SERVER_CONTROLLER, > >> ModelController.class, mcValue); > >> ... > >> WHAT_I_WANT = mcValue.getValue().createClient(...) > >> > >> But obviously, that's no good for something running outside of the WildFly > >> container (albeit in the same JVM). > >> > >> Any hope at all? I was thinking some trickery on the order of what ByteMan > >> does in order to figure out a way to obtain a local ModelController? But > >> that's a last ditch effort :) Hoping there is something that uses a > >> little less witchcraft. From david.lloyd at redhat.com Mon Mar 13 13:44:40 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 13 Mar 2017 12:44:40 -0500 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> Message-ID: <04e4cdbc-9b70-84d2-318a-294a489cc356@redhat.com> To me it seems like, when running in WildFly you always want it to be a subsystem, and when running not in WildFly, you always want it to be an agent. In other words, you're describing two pieces of software (with some shared/common code) that do two different things in two different scenarios, and you're trying to make it all one. If my understanding is correct, I don't think this is really going to save any work compared to supporting two different things with common code. If anything, the combinatory approach going to cause extra work due to trying to make a square-and-round peg try to fit in a square-or-round hole. On 03/13/2017 12:19 PM, John Mazzitelli wrote: > OK, here's the basic gist of what this is for - I'll try to keep it short. > > WHAT THE AGENT DOES: > > The "Hawkular WildFly Agent" looks at the tree of resources in its monitored servers (e.g. for WildFly servers, things like "/subsystem=datasources/data-source=MyH2" are resources; for JMX MBeanServers, MBeans are resources), and collects metrics from those resources. It stores that inventory and metric data to a backend Hawkular Server. Systems like ManageIQ, CloudForms, and even things like Grafana can then display in their UIs the inventory details (e.g. "here's a list of your 5 EAP servers"), and pretty graphs of all their metrics (e.g. "here's what your 5 EAP servers' heap memory usages look like"). > > HOW THE AGENT RUNS TODAY: > > Today, Hawkular WildFly Agent MUST BE installed as a subsystem. It can be installed in EAP 6.4, EAP 7.0/7.1, and their associated WildFly versions - but it has to be hosted in one of those things because it is implemented as a subsystem extension. It can be installed in a standalone server or a host controller. It can collect inventory and metric data for the server it is running in. > > WHY WE WANT TO CHANGE: > > But we have received feedback that "it would be nice to support this agent in a bunch of other projects that are not EAP based." Think Karaf-based or vert-x based applications that expose inventory/metrics over JMX. We want to collect inventory and metrics from non-EAP-based products that expose JMX so ManageIQ and CloudForms can see them just like EAP-based projects can be seen today. > > So I refactored the Hawkular Agent core engine so it can run EITHER as a subsystem extension OR as a VM java agent. > > Then I have received feedback, "it would be nice to not have to support and maintain both versions of the agent - just support the Java Agent since it can monitor EAP and non-EAP based products. Throw away the subsystem one since it isn't needed anymore." > > WHAT IS THE PROBLEM? > > Right now, I have a java agent that is working well and can support both EAP and non-EAP based products. However, there are two problems: > > 1) Unrelated to this email thread, but I can't run this java agent in a Host controller (that's this JIRA: https://issues.jboss.org/browse/WFCORE-2526) - the workaround for this is to run the agent in its own JVM and remotely monitor the Host Controller. Not ideal because now it has to go through the remote management endpoint. Other workaround is to rip out jboss logging entirely from my agent and use some other logging framework. But again, ignore that for now. Not relevant to this discussion. > > 2) Even though the agent is running co-located inside the WildFly JVM as a javaagent, it can't get a local client so it can talk locally to it. It must go through the remote management endpoint. I would like this agent to get a local ModelController so it can build clients like it can today when running in a subsystem. The agent (when running as a subsystem) uses code similar to this: > > InjectedValue mcValue = new InjectedValue<>(); > ... > ((ServiceBuilder) bldr).addDependency(Services.JBOSS_SERVER_CONTROLLER, ModelController.class, mcValue); > ... > WHAT_I_WANT = mcValue.getValue().createClient(...) > > I need something similar in the javaagent - I need to get that local ModelController so the javaagent can build a local client and thus avoid having to configure the WildFly remote management interface and avoid having to make remote calls to its co-located WildFly Server. > > Hopefully, that makes sense. Sorry - wasn't short :) > > ----- Original Message ----- >> Hi John, >> >> Before moving with non-traditional access like this I think we need to make >> sure the overall strategy behind what you are building is something we can >> support over multiple releases. Of course, a lot of that depends on your >> compatibility expectations. >> >>> On Mar 13, 2017, at 10:08 AM, Brian Stansberry >>> wrote: >>> >>> Once you get access to MSC, do not use Services.JBOSS_SERVER_CONTROLLER to >>> get a ModelController to create the client. That method is deprecated and >>> I plan to remove it in the next release (WildFly Core 4 / WildFly 12). >>> >>> Use >>> ServiceName.parse("org.wildfly.managment.model-controller-client-factory?) >>> to get a ModelControllerClientFactory and use it to create a client, >>> calling createSuperUserClient. >>> >>> Note that if you want that client to work properly in a SecurityManager >>> enabled environment your code will need to have >>> org.jboss.as.controller.security.ControllerPermission#PERFORM_IN_VM_CALL >>> PERFORM_IN_VM_CALL. The security guys added in that requirement for WF >>> Core 3. Note that applies even if you use the deprecated >>> ModelController.createClient method. >>> >>>> On Mar 12, 2017, at 8:32 PM, Stuart Douglas >>>> wrote: >>>> >>>> You can call >>>> org.jboss.as.server.CurrentServiceContainer#getServiceContainer() to do >>>> this, however it is trickey from a JavaAgent (as the module will not be >>>> available from the agent's class loader). >>>> >>>> Unfortunately there is no getting around this, as none of the API classes >>>> you need will be available in the module. As I see it you have a few >>>> different options: >>>> >>>> 1) Use reflection to get hold of this class, and then use reflection to >>>> make the calls >>>> 2) Create a class that does this directly, and then make sure it is loaded >>>> from the server module (which has access to the classes you need). >>>> >>>> There may be some other options, but that is all I can think of of the top >>>> of my head. >>>> >>>> If you want more info on how to implement either of these approaches feel >>>> free to ask me on hipchat. >>>> >>>> Stuart >>>> >>>> On Sat, Mar 11, 2017 at 5:43 PM, John Mazzitelli wrote: >>>> OK, here's another one where I need some secret magical sauce - hoping >>>> someone knows of a technique I can use. >>>> >>>> Suppose I have a javaagent installed in a WildFly server (using the >>>> standard -javaagent VM argument). >>>> >>>> The javaagent would like to talk to the WildFly Server it is co-located >>>> with. Since it is in the same VM, the javaagent wants to avoid it looking >>>> like a remote call. >>>> >>>> But I know of no way to obtain a local ModelController instance to build a >>>> client short of injecting some service or subsystem into WildFly itself >>>> (something I would like to avoid). >>>> >>>> If the javaagent were instead a subsystem extension, it could do something >>>> like this: >>>> >>>> InjectedValue mcValue = new InjectedValue<>(); >>>> ... >>>> ((ServiceBuilder) bldr).addDependency(Services.JBOSS_SERVER_CONTROLLER, >>>> ModelController.class, mcValue); >>>> ... >>>> WHAT_I_WANT = mcValue.getValue().createClient(...) >>>> >>>> But obviously, that's no good for something running outside of the WildFly >>>> container (albeit in the same JVM). >>>> >>>> Any hope at all? I was thinking some trickery on the order of what ByteMan >>>> does in order to figure out a way to obtain a local ModelController? But >>>> that's a last ditch effort :) Hoping there is something that uses a >>>> little less witchcraft. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML From jason.greene at redhat.com Mon Mar 13 13:51:32 2017 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 13 Mar 2017 12:51:32 -0500 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> Message-ID: Thanks for the info. Sorry to be annoying and ask the same question over and over, but what is missing from the remote management protocol that WildFly already provides? > On Mar 13, 2017, at 12:19 PM, John Mazzitelli wrote: > > OK, here's the basic gist of what this is for - I'll try to keep it short. > > WHAT THE AGENT DOES: > > The "Hawkular WildFly Agent" looks at the tree of resources in its monitored servers (e.g. for WildFly servers, things like "/subsystem=datasources/data-source=MyH2" are resources; for JMX MBeanServers, MBeans are resources), and collects metrics from those resources. It stores that inventory and metric data to a backend Hawkular Server. Systems like ManageIQ, CloudForms, and even things like Grafana can then display in their UIs the inventory details (e.g. "here's a list of your 5 EAP servers"), and pretty graphs of all their metrics (e.g. "here's what your 5 EAP servers' heap memory usages look like"). > > HOW THE AGENT RUNS TODAY: > > Today, Hawkular WildFly Agent MUST BE installed as a subsystem. It can be installed in EAP 6.4, EAP 7.0/7.1, and their associated WildFly versions - but it has to be hosted in one of those things because it is implemented as a subsystem extension. It can be installed in a standalone server or a host controller. It can collect inventory and metric data for the server it is running in. > > WHY WE WANT TO CHANGE: > > But we have received feedback that "it would be nice to support this agent in a bunch of other projects that are not EAP based." Think Karaf-based or vert-x based applications that expose inventory/metrics over JMX. We want to collect inventory and metrics from non-EAP-based products that expose JMX so ManageIQ and CloudForms can see them just like EAP-based projects can be seen today. > > So I refactored the Hawkular Agent core engine so it can run EITHER as a subsystem extension OR as a VM java agent. > > Then I have received feedback, "it would be nice to not have to support and maintain both versions of the agent - just support the Java Agent since it can monitor EAP and non-EAP based products. Throw away the subsystem one since it isn't needed anymore." > > WHAT IS THE PROBLEM? > > Right now, I have a java agent that is working well and can support both EAP and non-EAP based products. However, there are two problems: > > 1) Unrelated to this email thread, but I can't run this java agent in a Host controller (that's this JIRA: https://issues.jboss.org/browse/WFCORE-2526) - the workaround for this is to run the agent in its own JVM and remotely monitor the Host Controller. Not ideal because now it has to go through the remote management endpoint. Other workaround is to rip out jboss logging entirely from my agent and use some other logging framework. But again, ignore that for now. Not relevant to this discussion. > > 2) Even though the agent is running co-located inside the WildFly JVM as a javaagent, it can't get a local client so it can talk locally to it. It must go through the remote management endpoint. I would like this agent to get a local ModelController so it can build clients like it can today when running in a subsystem. The agent (when running as a subsystem) uses code similar to this: > > InjectedValue mcValue = new InjectedValue<>(); > ... > ((ServiceBuilder) bldr).addDependency(Services.JBOSS_SERVER_CONTROLLER, ModelController.class, mcValue); > ... > WHAT_I_WANT = mcValue.getValue().createClient(...) > > I need something similar in the javaagent - I need to get that local ModelController so the javaagent can build a local client and thus avoid having to configure the WildFly remote management interface and avoid having to make remote calls to its co-located WildFly Server. > > Hopefully, that makes sense. Sorry - wasn't short :) > > ----- Original Message ----- >> Hi John, >> >> Before moving with non-traditional access like this I think we need to make >> sure the overall strategy behind what you are building is something we can >> support over multiple releases. Of course, a lot of that depends on your >> compatibility expectations. >> >>> On Mar 13, 2017, at 10:08 AM, Brian Stansberry >>> wrote: >>> >>> Once you get access to MSC, do not use Services.JBOSS_SERVER_CONTROLLER to >>> get a ModelController to create the client. That method is deprecated and >>> I plan to remove it in the next release (WildFly Core 4 / WildFly 12). >>> >>> Use >>> ServiceName.parse("org.wildfly.managment.model-controller-client-factory?) >>> to get a ModelControllerClientFactory and use it to create a client, >>> calling createSuperUserClient. >>> >>> Note that if you want that client to work properly in a SecurityManager >>> enabled environment your code will need to have >>> org.jboss.as.controller.security.ControllerPermission#PERFORM_IN_VM_CALL >>> PERFORM_IN_VM_CALL. The security guys added in that requirement for WF >>> Core 3. Note that applies even if you use the deprecated >>> ModelController.createClient method. >>> >>>> On Mar 12, 2017, at 8:32 PM, Stuart Douglas >>>> wrote: >>>> >>>> You can call >>>> org.jboss.as.server.CurrentServiceContainer#getServiceContainer() to do >>>> this, however it is trickey from a JavaAgent (as the module will not be >>>> available from the agent's class loader). >>>> >>>> Unfortunately there is no getting around this, as none of the API classes >>>> you need will be available in the module. As I see it you have a few >>>> different options: >>>> >>>> 1) Use reflection to get hold of this class, and then use reflection to >>>> make the calls >>>> 2) Create a class that does this directly, and then make sure it is loaded >>>> from the server module (which has access to the classes you need). >>>> >>>> There may be some other options, but that is all I can think of of the top >>>> of my head. >>>> >>>> If you want more info on how to implement either of these approaches feel >>>> free to ask me on hipchat. >>>> >>>> Stuart >>>> >>>> On Sat, Mar 11, 2017 at 5:43 PM, John Mazzitelli wrote: >>>> OK, here's another one where I need some secret magical sauce - hoping >>>> someone knows of a technique I can use. >>>> >>>> Suppose I have a javaagent installed in a WildFly server (using the >>>> standard -javaagent VM argument). >>>> >>>> The javaagent would like to talk to the WildFly Server it is co-located >>>> with. Since it is in the same VM, the javaagent wants to avoid it looking >>>> like a remote call. >>>> >>>> But I know of no way to obtain a local ModelController instance to build a >>>> client short of injecting some service or subsystem into WildFly itself >>>> (something I would like to avoid). >>>> >>>> If the javaagent were instead a subsystem extension, it could do something >>>> like this: >>>> >>>> InjectedValue mcValue = new InjectedValue<>(); >>>> ... >>>> ((ServiceBuilder) bldr).addDependency(Services.JBOSS_SERVER_CONTROLLER, >>>> ModelController.class, mcValue); >>>> ... >>>> WHAT_I_WANT = mcValue.getValue().createClient(...) >>>> >>>> But obviously, that's no good for something running outside of the WildFly >>>> container (albeit in the same JVM). >>>> >>>> Any hope at all? I was thinking some trickery on the order of what ByteMan >>>> does in order to figure out a way to obtain a local ModelController? But >>>> that's a last ditch effort :) Hoping there is something that uses a >>>> little less witchcraft. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From mazz at redhat.com Mon Mar 13 14:18:44 2017 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 13 Mar 2017 14:18:44 -0400 (EDT) Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> Message-ID: <1897667823.4131201.1489429124718.JavaMail.zimbra@redhat.com> > Thanks for the info. Sorry to be annoying and ask the same question over and > over, but what is missing from the remote management protocol that WildFly > already provides? Nothing is "missing" from it per-se. As a workaround, the agent is going through this remote management protocol so it can do its thing. One feature I don't think I mentioned is the agent can monitor remote WildFly (and Jolokia) servers - I use that feature to monitor its co-located local WildFly server. Its local WildFly simply looks like a remote server and it monitors it as such. So the javaagent, even though it is running co-located in the same VM as the WildFly Server, is talking over the remote management endpoint to its WildFly server as a workaround for this inability to obtain a local client. However: 1) It requires the user to configure the remote management endpoint simply so it can be monitored by an agent that is already running co-located in the VM. I already envision the customer asking "Tell me again why I need to configure the remote management interface so its javaagent can talk to it?". The customer should actually be able to disable the remote endpoint entirely (perhaps to lock it down and disallow jboss-cli access?) and have this agent still work - since it really doesn't need to (or at least should not have to) talk to the remote endpoint. 2) It requires the agent to be told what this endpoint is - if the user actually bound the remote endpoint to a non-default IP (not 127.0.0.1) or non-default port (not 9990), then they have to make sure they also configure the agent to tell it where the remote endpoint is. Potential place for user-error if they forget to do that. I suppose the agent could read standalone.xml to find out what the mgmt address/port is but a) what if its not standalone.xml? Maybe the user started with a different config? What if its not standalone but deployed in domain mode? Must look at a different config file. b) now the agent has to know how to parse standalone.xml. This can all be avoided if we just didn't have to go over the remote endpoint. 3) Seems inefficient to have to go over a remote endpoint (even if its over a loopback device) when the agent should just be able to make intra-VM Java API calls to do this. From jason.greene at redhat.com Mon Mar 13 14:40:48 2017 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 13 Mar 2017 13:40:48 -0500 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <1897667823.4131201.1489429124718.JavaMail.zimbra@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> <1897667823.4131201.1489429124718.JavaMail.zimbra@redhat.com> Message-ID: > On Mar 13, 2017, at 1:18 PM, John Mazzitelli wrote: > >> Thanks for the info. Sorry to be annoying and ask the same question over and >> over, but what is missing from the remote management protocol that WildFly >> already provides? > > Nothing is "missing" from it per-se. As a workaround, the agent is going through this remote management protocol so it can do its thing. One feature I don't think I mentioned is the agent can monitor remote WildFly (and Jolokia) servers - I use that feature to monitor its co-located local WildFly server. Its local WildFly simply looks like a remote server and it monitors it as such. So the javaagent, even though it is running co-located in the same VM as the WildFly Server, is talking over the remote management endpoint to its WildFly server as a workaround for this inability to obtain a local client. > > However: > > 1) It requires the user to configure the remote management endpoint simply so it can be monitored by an agent that is already running co-located in the VM. I already envision the customer asking "Tell me again why I need to configure the remote management interface so its javaagent can talk to it?". The customer should actually be able to disable the remote endpoint entirely (perhaps to lock it down and disallow jboss-cli access?) and have this agent still work - since it really doesn't need to (or at least should not have to) talk to the remote endpoint. > > 2) It requires the agent to be told what this endpoint is - if the user actually bound the remote endpoint to a non-default IP (not 127.0.0.1) or non-default port (not 9990), then they have to make sure they also configure the agent to tell it where the remote endpoint is. Potential place for user-error if they forget to do that. I suppose the agent could read standalone.xml to find out what the mgmt address/port is but a) what if its not standalone.xml? Maybe the user started with a different config? What if its not standalone but deployed in domain mode? Must look at a different config file. b) now the agent has to know how to parse standalone.xml. This can all be avoided if we just didn't have to go over the remote endpoint. > > 3) Seems inefficient to have to go over a remote endpoint (even if its over a loopback device) when the agent should just be able to make intra-VM Java API calls to do this. > Thanks John, Although I am more generally asking why an agent is needed at all. Why not simply pull from the remote EAP node using a user that is setup for monitoring? That would reduce the software installation and maintenance overhead to just a configuration overhead. -Jason From mazz at redhat.com Mon Mar 13 14:41:10 2017 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 13 Mar 2017 14:41:10 -0400 (EDT) Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <04e4cdbc-9b70-84d2-318a-294a489cc356@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> <04e4cdbc-9b70-84d2-318a-294a489cc356@redhat.com> Message-ID: <85643437.4135926.1489430470707.JavaMail.zimbra@redhat.com> > To me it seems like, when running in WildFly you always want it to be a > subsystem, and when running not in WildFly, you always want it to be an > agent. > > In other words, you're describing two pieces of software (with some > shared/common code) that do two different things in two different > scenarios, and you're trying to make it all one. > > If my understanding is correct, I don't think this is really going to > save any work compared to supporting two different things with common > code. If anything, the combinatory approach going to cause extra work > due to trying to make a square-and-round peg try to fit in a > square-or-round hole. Well, actually the "have two agents" is going to be more complicated than this "all-in-one agent" - certainly more complicated from a support/maintenance point of view. I have the all-in-one "java agent" working now (aside from those two issues I mentioned). If I could just get a local ModelController, the same piece of software can monitor: 1) Local WildFly/EAP servers (standalone and host controller) 2) Local JMX servers 3) Remote WildFly/EAP servers (standalone and host controller) 4) Remote JMX Servers Having this all-in-one javaagent (versus having two separate agents) means the amount of work this would save is quite a lot. For example: a) We would no longer have to support and maintain the subsystem extension code itself (not to mention all the ancillary code like the feature pack mvn module). b) We no longer would have to support/maintain/document two different configuration files (one for the in standalone.xml/host.xml and one for the javaagent yaml file) c) We no longer have to support the agent installer. This agent installer is a piece of additional software that is needed because people complained about having to manually copy the binaries in the add-ons dir and to configure the XML to get the agent installed (along with its related stuff like any required and that the agent needs). We ended up writing an installer that can install the add-ons binaries and inject the necessary XML in standalone/host xml so the user doesn't have to. But upgrading such an installment is still a problem - that installer doesn't support upgrading the XML. Does WildFly today have a subsystem extension installer/upgrader that allows users to install add-ons in their own WildFly servers so a user doesn't have to configure standalone.xml/host.xml with the add-on's required XML? Does it modify/upgrade that XML in standalone.xml/host.xml if an older version of the add-on already exists? If such a tool exists, that would help a lot. Right now, it is a pain to have to write and maintain the agent's own installer. :) If WildFly has such a tool available already, then this issue with having to maintain/support an installer goes away for me. I did not think such a thing existed, at least not at the time when we wrote this agent installer. From mazz at redhat.com Mon Mar 13 15:08:32 2017 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 13 Mar 2017 15:08:32 -0400 (EDT) Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> <1897667823.4131201.1489429124718.JavaMail.zimbra@redhat.com> Message-ID: <553352171.4143441.1489432112718.JavaMail.zimbra@redhat.com> > Although I am more generally asking why an agent is needed at all. Why not > simply pull from the remote EAP node using a user that is setup for > monitoring? That would reduce the software installation and maintenance > overhead to just a configuration overhead. Can you clarify? Are you asking, "Why not have a single agent running "somewhere" and have it pull from a collection of remote EAP nodes?" In fact, this Hawkular Agent does support this kind of deployment (the Agent can be told to monitor N remote servers whether or not those remote servers are running on the same machine or somewhere else on the network). One issue with something like that is - most customers do not want to expose their remote management endpoints past the localhost boundary. In that case, this means the agent must be at least installed on the same machine as the EAP node itself even if it isn't running in the same JVM. But now they have to install two things - the agent and the WildFly - albeit on the same machine. If that is the case, why not just bundle the agent together with WildFly so you have a single distribution we can call "instrumented WildFly" that a user has to worry about installing? You run your instrumented Wildfly server normally but now you automatically get inventory/metrics uploaded and stored to CloudForms which can then immediately begin to manage it. No need to install and run a separate agent process. I would like to ask Thomas Heute to reply to this thread as he has more details about why we want it this way - he's dealt alot more with user requirements and the like. Thomas? From jason.greene at redhat.com Mon Mar 13 16:50:29 2017 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 13 Mar 2017 15:50:29 -0500 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <553352171.4143441.1489432112718.JavaMail.zimbra@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> <1897667823.4131201.1489429124718.JavaMail.zimbra@redhat.com> <553352171.4143441.1489432112718.JavaMail.zimbra@redhat.com> Message-ID: <9F0C28AA-F938-456E-B366-D53A76DD9611@redhat.com> > On Mar 13, 2017, at 2:08 PM, John Mazzitelli wrote: > >> Although I am more generally asking why an agent is needed at all. Why not >> simply pull from the remote EAP node using a user that is setup for >> monitoring? That would reduce the software installation and maintenance >> overhead to just a configuration overhead. > > Can you clarify? Are you asking, ?Why not have a single agent running "somewhere" and have it pull from a collection of remote EAP nodes?" Right thats what I was asking. > > In fact, this Hawkular Agent does support this kind of deployment (the Agent can be told to monitor N remote servers whether or not those remote servers are running on the same machine or somewhere else on the network). > > One issue with something like that is - most customers do not want to expose their remote management endpoints past the localhost boundary. It?s very common for our users to do this (for example you can even create users which can only do monitoring operations); so I?ll take it to mean that your understand is that Hawkular?s prefer the call home approach, which is fair enough. I only ask since the approach is being revisited again. > In that case, this means the agent must be at least installed on the same machine as the EAP node itself even if it isn't running in the same JVM. But now they have to install two things - the agent and the WildFly - albeit on the same machine. > If that is the case, why not just bundle the agent together with WildFly so you have a single distribution we can call "instrumented WildFly" that a user has to worry about installing? You run your instrumented Wildfly server normally but now you automatically get inventory/metrics uploaded and stored to CloudForms which can then immediately begin to manage it. No need to install and run a separate agent process. I think thats a totally reasonable approach. The issue in the past was that the lifecycles didn?t match (I can?t remember the details as to why). If things were to remain as a subsystem that has an independent lifecycle, in the future it would be installable via the wildfly provisioning tool (once available). That includes automating adding config blocks as part of installation. If the lifecycles can match, and there is a reliable compatibility contract for the protocol, then we could just merge the capability into the core code. If you go the agent route though then there is not much we can do to improve the usability as our tooling isn?t going to be able to resolve the possible conflicts that arrive when more than one thing wants to own the bootstrap of the server. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From david.lloyd at redhat.com Mon Mar 13 18:00:14 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 13 Mar 2017 17:00:14 -0500 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <85643437.4135926.1489430470707.JavaMail.zimbra@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> <04e4cdbc-9b70-84d2-318a-294a489cc356@redhat.com> <85643437.4135926.1489430470707.JavaMail.zimbra@redhat.com> Message-ID: <806a0c8d-8dba-c803-b692-df27ea4e5eb2@redhat.com> On 03/13/2017 01:41 PM, John Mazzitelli wrote: >> To me it seems like, when running in WildFly you always want it to be a >> subsystem, and when running not in WildFly, you always want it to be an >> agent. >> >> In other words, you're describing two pieces of software (with some >> shared/common code) that do two different things in two different >> scenarios, and you're trying to make it all one. >> >> If my understanding is correct, I don't think this is really going to >> save any work compared to supporting two different things with common >> code. If anything, the combinatory approach going to cause extra work >> due to trying to make a square-and-round peg try to fit in a >> square-or-round hole. > > Well, actually the "have two agents" is going to be more complicated than this "all-in-one agent" - certainly more complicated from a support/maintenance point of view. > > I have the all-in-one "java agent" working now (aside from those two issues I mentioned). If I could just get a local ModelController, the same piece of software can monitor: > > 1) Local WildFly/EAP servers (standalone and host controller) > 2) Local JMX servers > 3) Remote WildFly/EAP servers (standalone and host controller) > 4) Remote JMX Servers > > Having this all-in-one javaagent (versus having two separate agents) means the amount of work this would save is quite a lot. For example: > > a) We would no longer have to support and maintain the subsystem extension code itself (not to mention all the ancillary code like the feature pack mvn module). > > b) We no longer would have to support/maintain/document two different configuration files (one for the in standalone.xml/host.xml and one for the javaagent yaml file) > > c) We no longer have to support the agent installer. This agent installer is a piece of additional software that is needed because people complained about having to manually copy the binaries in the add-ons dir and to configure the XML to get the agent installed (along with its related stuff like any required and that the agent needs). We ended up writing an installer that can install the add-ons binaries and inject the necessary XML in standalone/host xml so the user doesn't have to. But upgrading such an installment is still a problem - that installer doesn't support upgrading the XML. > > Does WildFly today have a subsystem extension installer/upgrader that allows users to install add-ons in their own WildFly servers so a user doesn't have to configure standalone.xml/host.xml with the add-on's required XML? Generally speaking, no, not yet, though you can use the CLI to do and script various things. > Does it modify/upgrade that XML in standalone.xml/host.xml if an older version of the add-on already exists? This is automatically done at server start in most if not all cases, not by any tool but by the management model itself. The XML isn't the model; it's just a serialization of it. Interaction with the configuration often (usually?) is done via CLI and the console, rather than by manipulating the XML itself. > If such a tool exists, that would help a lot. Right now, it is a pain to have to write and maintain the agent's own installer. :) If WildFly has such a tool available already, then this issue with having to maintain/support an installer goes away for me. I did not think such a thing existed, at least not at the time when we wrote this agent installer. If you're manipulating XML directly then it's possible that the CLI can do most of what your installer is doing in a more resilient manner, and possibly a simpler manner as well. Have you looked into it? -- - DML From david.lloyd at redhat.com Mon Mar 13 18:09:16 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 13 Mar 2017 17:09:16 -0500 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <806a0c8d-8dba-c803-b692-df27ea4e5eb2@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> <04e4cdbc-9b70-84d2-318a-294a489cc356@redhat.com> <85643437.4135926.1489430470707.JavaMail.zimbra@redhat.com> <806a0c8d-8dba-c803-b692-df27ea4e5eb2@redhat.com> Message-ID: Also want to add that it is possible that a given JVM will have zero-or-more WildFly instances in it. So, the phrase "find the container" doesn't really have meaning as there could be many (granted it's not usually practical to do this *today*, but I guarantee that it will be possible and practical in the not-too-distant future). On 03/13/2017 05:00 PM, David M. Lloyd wrote: > On 03/13/2017 01:41 PM, John Mazzitelli wrote: >>> To me it seems like, when running in WildFly you always want it to be a >>> subsystem, and when running not in WildFly, you always want it to be an >>> agent. >>> >>> In other words, you're describing two pieces of software (with some >>> shared/common code) that do two different things in two different >>> scenarios, and you're trying to make it all one. >>> >>> If my understanding is correct, I don't think this is really going to >>> save any work compared to supporting two different things with common >>> code. If anything, the combinatory approach going to cause extra work >>> due to trying to make a square-and-round peg try to fit in a >>> square-or-round hole. >> >> Well, actually the "have two agents" is going to be more complicated >> than this "all-in-one agent" - certainly more complicated from a >> support/maintenance point of view. >> >> I have the all-in-one "java agent" working now (aside from those two >> issues I mentioned). If I could just get a local ModelController, the >> same piece of software can monitor: >> >> 1) Local WildFly/EAP servers (standalone and host controller) >> 2) Local JMX servers >> 3) Remote WildFly/EAP servers (standalone and host controller) >> 4) Remote JMX Servers >> >> Having this all-in-one javaagent (versus having two separate agents) >> means the amount of work this would save is quite a lot. For example: >> >> a) We would no longer have to support and maintain the subsystem >> extension code itself (not to mention all the ancillary code like the >> feature pack mvn module). >> >> b) We no longer would have to support/maintain/document two different >> configuration files (one for the in >> standalone.xml/host.xml and one for the javaagent yaml file) >> >> c) We no longer have to support the agent installer. This agent >> installer is a piece of additional software that is needed because >> people complained about having to manually copy the binaries in the >> add-ons dir and to configure the XML to get the agent >> installed (along with its related stuff like any required >> and that the agent needs). We >> ended up writing an installer that can install the add-ons binaries >> and inject the necessary XML in standalone/host xml so the user >> doesn't have to. But upgrading such an installment is still a problem >> - that installer doesn't support upgrading the XML. >> >> Does WildFly today have a subsystem extension installer/upgrader that >> allows users to install add-ons in their own WildFly servers so a user >> doesn't have to configure standalone.xml/host.xml with the add-on's >> required XML? > > Generally speaking, no, not yet, though you can use the CLI to do and > script various things. > >> Does it modify/upgrade that XML in standalone.xml/host.xml if an older >> version of the add-on already exists? > > This is automatically done at server start in most if not all cases, not > by any tool but by the management model itself. The XML isn't the > model; it's just a serialization of it. Interaction with the > configuration often (usually?) is done via CLI and the console, rather > than by manipulating the XML itself. > >> If such a tool exists, that would help a lot. Right now, it is a pain >> to have to write and maintain the agent's own installer. :) If WildFly >> has such a tool available already, then this issue with having to >> maintain/support an installer goes away for me. I did not think such a >> thing existed, at least not at the time when we wrote this agent >> installer. > > If you're manipulating XML directly then it's possible that the CLI can > do most of what your installer is doing in a more resilient manner, and > possibly a simpler manner as well. Have you looked into it? > -- - DML From brian.stansberry at redhat.com Mon Mar 13 20:02:05 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 13 Mar 2017 19:02:05 -0500 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <806a0c8d-8dba-c803-b692-df27ea4e5eb2@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> <04e4cdbc-9b70-84d2-318a-294a489cc356@redhat.com> <85643437.4135926.1489430470707.JavaMail.zimbra@redhat.com> <806a0c8d-8dba-c803-b692-df27ea4e5eb2@redhat.com> Message-ID: <2F4CEBC6-5820-4199-AFF1-2136A68614A0@redhat.com> > On Mar 13, 2017, at 5:00 PM, David M. Lloyd wrote: > > On 03/13/2017 01:41 PM, John Mazzitelli wrote: >>> To me it seems like, when running in WildFly you always want it to be a >>> subsystem, and when running not in WildFly, you always want it to be an >>> agent. >>> >>> In other words, you're describing two pieces of software (with some >>> shared/common code) that do two different things in two different >>> scenarios, and you're trying to make it all one. >>> >>> If my understanding is correct, I don't think this is really going to >>> save any work compared to supporting two different things with common >>> code. If anything, the combinatory approach going to cause extra work >>> due to trying to make a square-and-round peg try to fit in a >>> square-or-round hole. >> >> Well, actually the "have two agents" is going to be more complicated than this "all-in-one agent" - certainly more complicated from a support/maintenance point of view. >> >> I have the all-in-one "java agent" working now (aside from those two issues I mentioned). If I could just get a local ModelController, the same piece of software can monitor: >> >> 1) Local WildFly/EAP servers (standalone and host controller) Why do you need a ModelControllerClient to look at metrics? I believe metrics should be available over JMX. In another thread you asked about DMR->JMX and mentioned deployments. So if you want to do complex stuff like deployments, or really any writes, using a ModelControllerClient makes sense. But the "WHAT THE AGENT DOES:? section earlier in this thread just talks about metrics. >> 2) Local JMX servers >> 3) Remote WildFly/EAP servers (standalone and host controller) >> 4) Remote JMX Servers >> >> Having this all-in-one javaagent (versus having two separate agents) means the amount of work this would save is quite a lot. For example: >> >> a) We would no longer have to support and maintain the subsystem extension code itself (not to mention all the ancillary code like the feature pack mvn module). >> >> b) We no longer would have to support/maintain/document two different configuration files (one for the in standalone.xml/host.xml and one for the javaagent yaml file) >> >> c) We no longer have to support the agent installer. This agent installer is a piece of additional software that is needed because people complained about having to manually copy the binaries in the add-ons dir and to configure the XML to get the agent installed (along with its related stuff like any required and that the agent needs). This security and socket related config that used to be part of the server config is now in a yaml file the the javaagent is configured to access? >> We ended up writing an installer that can install the add-ons binaries and inject the necessary XML in standalone/host xml so the user doesn't have to. But upgrading such an installment is still a problem - that installer doesn't support upgrading the XML. >> >> Does WildFly today have a subsystem extension installer/upgrader that allows users to install add-ons in their own WildFly servers so a user doesn't have to configure standalone.xml/host.xml with the add-on's required XML? > > Generally speaking, no, not yet, though you can use the CLI to do and > script various things. > >> Does it modify/upgrade that XML in standalone.xml/host.xml if an older version of the add-on already exists? > > This is automatically done at server start in most if not all cases, not > by any tool but by the management model itself. The XML isn't the > model; it's just a serialization of it. This depends on what the upgrade is. The server will automatically move a subsystem config to the latest schema version, but if the new code has some new functionality we don?t automatically inject that into the config. Your parser for the old schema version could do that in theory, but generally that?s a bad practice. > Interaction with the > configuration often (usually?) is done via CLI and the console, rather > than by manipulating the XML itself. > >> If such a tool exists, that would help a lot. Right now, it is a pain to have to write and maintain the agent's own installer. :) If WildFly has such a tool available already, then this issue with having to maintain/support an installer goes away for me. I did not think such a thing existed, at least not at the time when we wrote this agent installer. > > If you're manipulating XML directly then it's possible that the CLI can > do most of what your installer is doing in a more resilient manner, and > possibly a simpler manner as well. Have you looked into it? > The EAP installer itself uses the CLI in this way. > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From mazz at redhat.com Mon Mar 13 20:42:01 2017 From: mazz at redhat.com (John Mazzitelli) Date: Mon, 13 Mar 2017 20:42:01 -0400 (EDT) Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <2F4CEBC6-5820-4199-AFF1-2136A68614A0@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> <04e4cdbc-9b70-84d2-318a-294a489cc356@redhat.com> <85643437.4135926.1489430470707.JavaMail.zimbra@redhat.com> <806a0c8d-8dba-c803-b692-df27ea4e5eb2@redhat.com> <2F4CEBC6-5820-4199-AFF1-2136A68614A0@redhat.com> Message-ID: <2071864914.4305665.1489452121798.JavaMail.zimbra@redhat.com> > >> 1) Local WildFly/EAP servers (standalone and host controller) > > Why do you need a ModelControllerClient to look at metrics? I believe metrics > should be available over JMX. In another thread you asked about DMR->JMX and > mentioned deployments. So if you want to do complex stuff like deployments, > or really any writes, using a ModelControllerClient makes sense. But the > "WHAT THE AGENT DOES:? section earlier in this thread just talks about > metrics. Two things: 1) Recall that I'm porting an existing agent subsystem that already supported all of this by going through ModelController client. So rather than re-write everything to go over JMX, I'm reusing/refactoring functionality I already have. Going this route let me have a fully functional javaagent in a couple days. 2) Plus, yes, as you state, I neglected to say it needs deployment functionality - that requires ModelControllerClient anyway. > >> c) We no longer have to support the agent installer. This agent installer > >> is a piece of additional software that is needed because people > >> complained about having to manually copy the binaries in the add-ons dir > >> and to configure the XML to get the agent installed (along > >> with its related stuff like any required and >> bindings> that the agent needs). > > This security and socket related config that used to be part of the server > config is now in a yaml file the the javaagent is configured to access? Yes. everything is now in yaml - nothing is in standalone.xml if using this javaagent. re: security-realms - I only need truststore definitions (not the full security-realm stuff) so that's all the yaml defines - truststore details. Of course, this means the loss of the vault, so I need a way to somehow obfuscate passwords - but if we are deploying this in OpenShift, I plan on using something like ${x} tokens in the yaml and being able to use OS secrets and somehow pass them to the agent without passwords in plaintext. > > If you're manipulating XML directly then it's possible that the CLI can > > do most of what your installer is doing in a more resilient manner, and > > possibly a simpler manner as well. Have you looked into it? > > > > The EAP installer itself uses the CLI in this way. Yes, I'm sure I could use a CLI script to do most of this. Do people find it acceptable to edit a CLI script if they want to change the default out of box config (as opposed to editing the XML)? How do you, for example, supply a CLI script that lays out a default set of config items for a subsystem but offer a way for customers to customize that out of box config (for example, let them give the installer a truststore with their certs, or let them give you IP addresses and ports they want to use for outbound socket bindings or things like that, if they want to use http skip security-realm definitions but if they want to use https, ask the user for security-realm/truststore details)? Does jboss-cli.sh provide ways to ask questions and set the values of attributes based on the answers? That would be cool. And if it has that functionality, I'm ashamed for not knowing about it :) Honestly, I never looked into whether the CLI can ask for user-input before applying a write-attribute command. Also the agent installer also copies binaries to the add-ons directory. It also optionally pulls down the EAP-specific wf-extension.zip (includes the extension module binaries for the add-ons directory and a default xml snippet appropriate for injection into that EAP version) from the hawkular server. It also determines if its installing in EAP 6.4 and if so uses different config than EAP7/Wildfly. So writing a set of CLI commands is most but not all it does. From brat000012001 at gmail.com Tue Mar 14 00:11:22 2017 From: brat000012001 at gmail.com (Peter Nalyvayko) Date: Tue, 14 Mar 2017 00:11:22 -0400 Subject: [wildfly-dev] Accessing ssl/trusted store from a servlet Message-ID: Hello, Is there an way to programmatically access the truststore configuration (the path to the store and the store password) defined by security-realm/authentication/truststore XML element in standalone.xml from a servlet? Thanks! --Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170314/6e0dd497/attachment.html From brian.stansberry at redhat.com Tue Mar 14 18:21:52 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 14 Mar 2017 17:21:52 -0500 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <2071864914.4305665.1489452121798.JavaMail.zimbra@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> <04e4cdbc-9b70-84d2-318a-294a489cc356@redhat.com> <85643437.4135926.1489430470707.JavaMail.zimbra@redhat.com> <806a0c8d-8dba-c803-b692-df27ea4e5eb2@redhat.com> <2F4CEBC6-5820-4199-AFF1-2136A68614A0@redhat.com> <2071864914.4305665.1489452121798.JavaMail.zimbra@redhat.com> Message-ID: <9696EE1E-D351-45C0-891A-3B6C2AE66FEC@redhat.com> Thanks for clarifying about JMX.* I?ll answer the question about offline CLI first. The offline CLI is not a substitute for a full featured installer. If all you need is some simple conditional logic, e.g. ?if subsystem=foo doesn?t exist, add it? or ?if subsystem=foo/newfeature=y doesn?t exist, add it? you could just execute the CLI with a script with that kind of logic. And people could certainly edit that kind of script to make simple tweaks. But if you want sophisticated interaction with the user you need something more. (That?s true with an approach based on changing xml too.) The offline CLI however is something that can be embedded in a more sophisticated installer and can provide that installer client access to the server configuration in a controlled way without any remote interaction involved. This thread is about a request for a hook to get non-remote client access to the server configuration which is why we are pointing to it. It?s a supported solution whose semantics we understand as opposed to something new and unspecified. Using it does not involve needing access to server internals like the ServiceContainer. I?m unclear what all the javaagent will do. Is it basically just an installer, something that is going to set up the existing subsystem? Or is the existing subsystem basically gone and now the only interaction with the WildFly container is via this ModelControllerClient you are trying to access, and also JMX? So all the interaction with the remote Hawkular server, including security thereof, is hidden inside the agent layer and is unknown to the WildFly server? Or are there other services being installed in or access from the WildFly container? Extending WildFly by changing standalone.conf/domain.conf to add stuff to JAVA_OPTS isn?t great. It has the same weaknesses as needing to edit standalone.xml, but in a new place. But it is actually easier to externalize some commands to run some code at boot (which AIUI is the only point of your using ?javaagent) to a well known location and have our launch scripts read that. Easier than reading and incorporating arbitrary chunks of xml config, which is the longstanding request in this area. And more powerful than reading and executing chunks of CLI script. * Tangent: TBH I?m not clear why this agent needs to be doing deployments. If it?s a general purpose monitoring agent reusable across a variety of types of processes, deployments are an odd fit. > On Mar 13, 2017, at 7:42 PM, John Mazzitelli wrote: > >>>> 1) Local WildFly/EAP servers (standalone and host controller) >> >> Why do you need a ModelControllerClient to look at metrics? I believe metrics >> should be available over JMX. In another thread you asked about DMR->JMX and >> mentioned deployments. So if you want to do complex stuff like deployments, >> or really any writes, using a ModelControllerClient makes sense. But the >> "WHAT THE AGENT DOES:? section earlier in this thread just talks about >> metrics. > > Two things: > > 1) Recall that I'm porting an existing agent subsystem that already supported all of this by going through ModelController client. So rather than re-write everything to go over JMX, I'm reusing/refactoring functionality I already have. Going this route let me have a fully functional javaagent in a couple days. > > 2) Plus, yes, as you state, I neglected to say it needs deployment functionality - that requires ModelControllerClient anyway. > Ok, thanks. >>>> c) We no longer have to support the agent installer. This agent installer >>>> is a piece of additional software that is needed because people >>>> complained about having to manually copy the binaries in the add-ons dir >>>> and to configure the XML to get the agent installed (along >>>> with its related stuff like any required and >>> bindings> that the agent needs). >> >> This security and socket related config that used to be part of the server >> config is now in a yaml file the the javaagent is configured to access? > > Yes. everything is now in yaml - nothing is in standalone.xml if using this javaagent. re: security-realms - I only need truststore definitions (not the full security-realm stuff) so that's all the yaml defines - truststore details. Of course, this means the loss of the vault, so I need a way to somehow obfuscate passwords - but if we are deploying this in OpenShift, I plan on using something like ${x} tokens in the yaml and being able to use OS secrets and somehow pass them to the agent without passwords in plaintext. > >>> If you're manipulating XML directly then it's possible that the CLI can >>> do most of what your installer is doing in a more resilient manner, and >>> possibly a simpler manner as well. Have you looked into it? >>> >> >> The EAP installer itself uses the CLI in this way. > > Yes, I'm sure I could use a CLI script to do most of this. Do people find it acceptable to edit a CLI script if they want to change the default out of box config (as opposed to editing the XML)? How do you, for example, supply a CLI script that lays out a default set of config items for a subsystem but offer a way for customers to customize that out of box config (for example, let them give the installer a truststore with their certs, or let them give you IP addresses and ports they want to use for outbound socket bindings or things like that, if they want to use http skip security-realm definitions but if they want to use https, ask the user for security-realm/truststore details)? Does jboss-cli.sh provide ways to ask questions and set the values of attributes based on the answers? No, but neither can simple things like xslt. > That would be cool. And if it has that functionality, I'm ashamed for not knowing about it :) Honestly, I never looked into whether the CLI can ask for user-input before applying a write-attribute command. > > Also the agent installer also copies binaries to the add-ons directory. It also optionally pulls down the EAP-specific wf-extension.zip (includes the extension module binaries for the add-ons directory and a default xml snippet appropriate for injection into that EAP version) from the hawkular server. It also determines if its installing in EAP 6.4 and if so uses different config than EAP7/Wildfly. > > So writing a set of CLI commands is most but not all it does. -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Wed Mar 15 05:16:39 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 15 Mar 2017 09:16:39 +0000 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <2071864914.4305665.1489452121798.JavaMail.zimbra@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> <04e4cdbc-9b70-84d2-318a-294a489cc356@redhat.com> <85643437.4135926.1489430470707.JavaMail.zimbra@redhat.com> <806a0c8d-8dba-c803-b692-df27ea4e5eb2@redhat.com> <2F4CEBC6-5820-4199-AFF1-2136A68614A0@redhat.com> <2071864914.4305665.1489452121798.JavaMail.zimbra@redhat.com> Message-ID: <139b6a66-8058-b01d-8daf-cbd9eb3e33d5@jboss.com> On 14/03/17 00:42, John Mazzitelli wrote: > Yes. everything is now in yaml - nothing is in standalone.xml if using this javaagent. re: security-realms - I only need truststore definitions (not the full security-realm stuff) so that's all the yaml defines - truststore details. Of course, this means the loss of the vault, so I need a way to somehow obfuscate passwords - but if we are deploying this in OpenShift, I plan on using something like ${x} tokens in the yaml and being able to use OS secrets and somehow pass them to the agent without passwords in plaintext. If this part just talking about configuration of the client connecting to the server or something else? From darran.lofthouse at jboss.com Wed Mar 15 05:58:23 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 15 Mar 2017 09:58:23 +0000 Subject: [wildfly-dev] Latest WildFly Elytron Test Results - 2017-03-15 Message-ID: <6ffe64e2-9e57-7009-68c1-9435a66bb12a@jboss.com> After last nights merges we currently stand at 23 failures: - https://ci.wildfly.org/viewLog.html?buildId=50650&buildTypeId=WF_MasterNewInvocationTests&tab=buildResultsDiv I am going to work on the 'RemotingLoginModuleTestCase' failures today which will hopefully remove 4. org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testNotAuthorizedClient org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testAuthorizedClient org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testNotAuthorizedClient org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testAuthorizedClient org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnlyBeforeCompletion org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationSucceeded org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnly org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationFailed org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnlyBeforeCompletion org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationSucceeded org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances From mazz at redhat.com Wed Mar 15 06:48:46 2017 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 15 Mar 2017 06:48:46 -0400 (EDT) Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <139b6a66-8058-b01d-8daf-cbd9eb3e33d5@jboss.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> <04e4cdbc-9b70-84d2-318a-294a489cc356@redhat.com> <85643437.4135926.1489430470707.JavaMail.zimbra@redhat.com> <806a0c8d-8dba-c803-b692-df27ea4e5eb2@redhat.com> <2F4CEBC6-5820-4199-AFF1-2136A68614A0@redhat.com> <2071864914.4305665.1489452121798.JavaMail.zimbra@redhat.com> <139b6a66-8058-b01d-8daf-cbd9eb3e33d5@jboss.com> Message-ID: <1394120471.5455390.1489574926610.JavaMail.zimbra@redhat.com> > On 14/03/17 00:42, John Mazzitelli wrote: > > Yes. everything is now in yaml - nothing is in standalone.xml if using this > > javaagent. re: security-realms - I only need truststore definitions (not > > the full security-realm stuff) so that's all the yaml defines - truststore > > details. Of course, this means the loss of the vault, so I need a way to > > somehow obfuscate passwords - but if we are deploying this in OpenShift, I > > plan on using something like ${x} tokens in the yaml and being able to use > > OS secrets and somehow pass them to the agent without passwords in > > plaintext. > > If this part just talking about configuration of the client connecting > to the server or something else? something else. it is talking about the full configuration of what was the subsystem itself (which is now the javaagent) From darran.lofthouse at jboss.com Wed Mar 15 09:03:24 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 15 Mar 2017 13:03:24 +0000 Subject: [wildfly-dev] Latest WildFly Elytron Test Results - 2017-03-15 In-Reply-To: <6ffe64e2-9e57-7009-68c1-9435a66bb12a@jboss.com> References: <6ffe64e2-9e57-7009-68c1-9435a66bb12a@jboss.com> Message-ID: This weeks port from ladybird to master we will also remove all the ignores from the test cases now passing to get them back into the regular CI runs: - https://github.com/wildfly-security-incubator/wildfly/pull/160 On 15/03/17 09:58, Darran Lofthouse wrote: > After last nights merges we currently stand at 23 failures: - > > https://ci.wildfly.org/viewLog.html?buildId=50650&buildTypeId=WF_MasterNewInvocationTests&tab=buildResultsDiv > > I am going to work on the 'RemotingLoginModuleTestCase' failures today > which will hopefully remove 4. > > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir > org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testNotAuthorizedClient > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testAuthorizedClient > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testNotAuthorizedClient > org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testAuthorizedClient > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnlyBeforeCompletion > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationSucceeded > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnly > org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationFailed > org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful > org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover > org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnlyBeforeCompletion > org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationSucceeded > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation > org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From brian.stansberry at redhat.com Wed Mar 15 09:36:02 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 15 Mar 2017 08:36:02 -0500 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> Message-ID: I was thinking about this yesterday and realized that an MCC accessed this way will be broken following a reload. An extension that obtains an internal client doesn?t have this issue as the entire subsystem goes away and is started again as part of the reload. But something that lives outside that cycle is going to need a different integration. > On Mar 13, 2017, at 10:08 AM, Brian Stansberry wrote: > > Once you get access to MSC, do not use Services.JBOSS_SERVER_CONTROLLER to get a ModelController to create the client. That method is deprecated and I plan to remove it in the next release (WildFly Core 4 / WildFly 12). > > Use ServiceName.parse("org.wildfly.managment.model-controller-client-factory?) to get a ModelControllerClientFactory and use it to create a client, calling createSuperUserClient. > > Note that if you want that client to work properly in a SecurityManager enabled environment your code will need to have org.jboss.as.controller.security.ControllerPermission#PERFORM_IN_VM_CALL PERFORM_IN_VM_CALL. The security guys added in that requirement for WF Core 3. Note that applies even if you use the deprecated ModelController.createClient method. > >> On Mar 12, 2017, at 8:32 PM, Stuart Douglas wrote: >> >> You can call org.jboss.as.server.CurrentServiceContainer#getServiceContainer() to do this, however it is trickey from a JavaAgent (as the module will not be available from the agent's class loader). >> >> Unfortunately there is no getting around this, as none of the API classes you need will be available in the module. As I see it you have a few different options: >> >> 1) Use reflection to get hold of this class, and then use reflection to make the calls >> 2) Create a class that does this directly, and then make sure it is loaded from the server module (which has access to the classes you need). >> >> There may be some other options, but that is all I can think of of the top of my head. >> >> If you want more info on how to implement either of these approaches feel free to ask me on hipchat. >> >> Stuart >> >> On Sat, Mar 11, 2017 at 5:43 PM, John Mazzitelli wrote: >> OK, here's another one where I need some secret magical sauce - hoping someone knows of a technique I can use. >> >> Suppose I have a javaagent installed in a WildFly server (using the standard -javaagent VM argument). >> >> The javaagent would like to talk to the WildFly Server it is co-located with. Since it is in the same VM, the javaagent wants to avoid it looking like a remote call. >> >> But I know of no way to obtain a local ModelController instance to build a client short of injecting some service or subsystem into WildFly itself (something I would like to avoid). >> >> If the javaagent were instead a subsystem extension, it could do something like this: >> >> InjectedValue mcValue = new InjectedValue<>(); >> ... >> ((ServiceBuilder) bldr).addDependency(Services.JBOSS_SERVER_CONTROLLER, ModelController.class, mcValue); >> ... >> WHAT_I_WANT = mcValue.getValue().createClient(...) >> >> But obviously, that's no good for something running outside of the WildFly container (albeit in the same JVM). >> >> Any hope at all? I was thinking some trickery on the order of what ByteMan does in order to figure out a way to obtain a local ModelController? But that's a last ditch effort :) Hoping there is something that uses a little less witchcraft. >> _______________________________________________ >> 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 > Manager, 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 Manager, Senior Principal Software Engineer JBoss by Red Hat From theute at redhat.com Wed Mar 15 09:44:33 2017 From: theute at redhat.com (Thomas Heute) Date: Wed, 15 Mar 2017 14:44:33 +0100 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <553352171.4143441.1489432112718.JavaMail.zimbra@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1627924931.4114723.1489425572622.JavaMail.zimbra@redhat.com> <1897667823.4131201.1489429124718.JavaMail.zimbra@redhat.com> <553352171.4143441.1489432112718.JavaMail.zimbra@redhat.com> Message-ID: On Mon, Mar 13, 2017 at 8:08 PM, John Mazzitelli wrote: > > Although I am more generally asking why an agent is needed at all. Why > not > > simply pull from the remote EAP node using a user that is setup for > > monitoring? That would reduce the software installation and maintenance > > overhead to just a configuration overhead. > > Can you clarify? Are you asking, "Why not have a single agent running > "somewhere" and have it pull from a collection of remote EAP nodes?" > > In fact, this Hawkular Agent does support this kind of deployment (the > Agent can be told to monitor N remote servers whether or not those remote > servers are running on the same machine or somewhere else on the network). > > One issue with something like that is - most customers do not want to > expose their remote management endpoints past the localhost boundary. In > that case, this means the agent must be at least installed on the same > machine as the EAP node itself even if it isn't running in the same JVM. > But now they have to install two things - the agent and the WildFly - > albeit on the same machine. If that is the case, why not just bundle the > agent together with WildFly so you have a single distribution we can call > "instrumented WildFly" that a user has to worry about installing? You run > your instrumented Wildfly server normally but now you automatically get > inventory/metrics uploaded and stored to CloudForms which can then > immediately begin to manage it. No need to install and run a separate agent > process. > > I would like to ask Thomas Heute to reply to this thread as he has more > details about why we want it this way - he's dealt alot more with user > requirements and the like. > > Thomas? > > We need to support multiple projects, in multiple environments, for different consumers. Multiple projects: - Wildfly - Fuse on Karaf - Fuse on Wildfly - Infinispan on a modified Wildfly - Tomcat -... Multiple environments: - Bare Metal / VM - OpenShift / docker containers Different consumers: - ManageIQ that requires monitoring(Metrics/Alerting) and operations (stop, reload, (un)deploy...) - Possibly OpenShift console (For metrics only, since the containers would be considered immutable) Our original route was to build specific agents for each project or at least each "container" (vert.x, Karaf, Wildfly), but talking to Kevin (in CC), he's concerned about the multiple agents for the different docker containers (as much as we were concerned for other reasons as we need to ask more to the various teams so that they can build/maintain their agents). Then came the idea of the javaagent (or rather the idea that we could turn our DMR/Wildfly specific subsystem into a very generic javaagent in a short amount of time), the Fuse team (Thomas in CC) validated the approach, it works for Fuse on Karaf and Fuse on Wildfly the same way, same configuration AFAIK. It simplifies a lot the number of pieces to release/maintain, the documentation, the quality... About the agent. We very much prefer to have 1 agent per standalone Wildfly for multiple reasons, one of those is that it's easy for a Wilfly user, add the agent (+ their config + their deployments) and provision machines with it. While if you have 1 agent for N Wildfly, it needs a way to discover the new instances, or worse, need manual configuration changes. For domain mode, we'd prefer to have 1 Wildfly per host (Or domain ? I never remember) controller, the discovery of new node is not a problem in this scenario, and then all the nodes of the EAP domain are using the same monitoring configuration. I hope this helps understanding the reasoning behind the initial ask. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170315/9536dc1d/attachment.html From mazz at redhat.com Wed Mar 15 09:52:28 2017 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 15 Mar 2017 09:52:28 -0400 (EDT) Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> Message-ID: <1389033577.5699744.1489585948185.JavaMail.zimbra@redhat.com> > I was thinking about this yesterday and realized that an MCC accessed this > way will be broken following a reload. An extension that obtains an internal > client doesn?t have this issue as the entire subsystem goes away and is > started again as part of the reload. But something that lives outside that > cycle is going to need a different integration. Mmmm... that would be bad. So, it would mean that anything that lives outside the subsystem extension cycle that uses that old MCC would somehow need to know to throw it away and obtain a new one. From david.lloyd at redhat.com Wed Mar 15 10:46:55 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 15 Mar 2017 09:46:55 -0500 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <1389033577.5699744.1489585948185.JavaMail.zimbra@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1389033577.5699744.1489585948185.JavaMail.zimbra@redhat.com> Message-ID: On 03/15/2017 08:52 AM, John Mazzitelli wrote: >> I was thinking about this yesterday and realized that an MCC accessed this >> way will be broken following a reload. An extension that obtains an internal >> client doesn?t have this issue as the entire subsystem goes away and is >> started again as part of the reload. But something that lives outside that >> cycle is going to need a different integration. > > > Mmmm... that would be bad. > > So, it would mean that anything that lives outside the subsystem extension cycle that uses that old MCC would somehow need to know to throw it away and obtain a new one. Because the line between thought experiment and reality is getting blurry, I want to come back around and spell out the basic facts. * Yes, making an agent to control WildFly instances to avoid a configuration step is theoretically possible. * No, it's not a good idea for multiple reasons, and it seems likely cause additional problems down the line. * Unless we have another fundamental change of architecture, I don't see us supporting this approach. * We have other, supported ways to solve the same problem (e.g. deploy a subsystem, use JMX, use the management API) and tools that can help support this approach (e.g. CLI scripting). -- - DML From mazz at redhat.com Wed Mar 15 11:16:26 2017 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 15 Mar 2017 11:16:26 -0400 (EDT) Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1389033577.5699744.1489585948185.JavaMail.zimbra@redhat.com> Message-ID: <766982666.5908894.1489590986163.JavaMail.zimbra@redhat.com> Well, as I said at the outset, "using the remote management API" is how it is working today. But when deployed within the same JVM as the WildFly/EAP server, seemed it would be more efficient with less required configuration if we could just grab a local client. ----- Original Message ----- > On 03/15/2017 08:52 AM, John Mazzitelli wrote: > >> I was thinking about this yesterday and realized that an MCC accessed this > >> way will be broken following a reload. An extension that obtains an > >> internal > >> client doesn?t have this issue as the entire subsystem goes away and is > >> started again as part of the reload. But something that lives outside that > >> cycle is going to need a different integration. > > > > > > Mmmm... that would be bad. > > > > So, it would mean that anything that lives outside the subsystem extension > > cycle that uses that old MCC would somehow need to know to throw it away > > and obtain a new one. > > Because the line between thought experiment and reality is getting > blurry, I want to come back around and spell out the basic facts. > > * Yes, making an agent to control WildFly instances to avoid a > configuration step is theoretically possible. > * No, it's not a good idea for multiple reasons, and it seems likely > cause additional problems down the line. > * Unless we have another fundamental change of architecture, I don't see > us supporting this approach. > * We have other, supported ways to solve the same problem (e.g. deploy a > subsystem, use JMX, use the management API) and tools that can help > support this approach (e.g. CLI scripting). > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From darran.lofthouse at jboss.com Wed Mar 15 11:56:31 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Wed, 15 Mar 2017 15:56:31 +0000 Subject: [wildfly-dev] a way to obtain local ModelController within javaagent? In-Reply-To: <766982666.5908894.1489590986163.JavaMail.zimbra@redhat.com> References: <468179728.2472858.1489213617029.JavaMail.zimbra@redhat.com> <538176167.2478448.1489214634533.JavaMail.zimbra@redhat.com> <2C041480-93C5-488C-96CB-F3E250928216@redhat.com> <1389033577.5699744.1489585948185.JavaMail.zimbra@redhat.com> <766982666.5908894.1489590986163.JavaMail.zimbra@redhat.com> Message-ID: <5419dd64-0baa-99d1-a45f-ca12d9b9d88a@jboss.com> One thing we are adding to WildFly 11 is a common client side configuration including security settings. This is used by clients such as the CLI. If this was in place the settings it contains would be available to you. On 15/03/17 15:16, John Mazzitelli wrote: > Well, as I said at the outset, "using the remote management API" is how it is working today. > > But when deployed within the same JVM as the WildFly/EAP server, seemed it would be more efficient with less required configuration if we could just grab a local client. > > ----- Original Message ----- >> On 03/15/2017 08:52 AM, John Mazzitelli wrote: >>>> I was thinking about this yesterday and realized that an MCC accessed this >>>> way will be broken following a reload. An extension that obtains an >>>> internal >>>> client doesn?t have this issue as the entire subsystem goes away and is >>>> started again as part of the reload. But something that lives outside that >>>> cycle is going to need a different integration. >>> >>> >>> Mmmm... that would be bad. >>> >>> So, it would mean that anything that lives outside the subsystem extension >>> cycle that uses that old MCC would somehow need to know to throw it away >>> and obtain a new one. >> >> Because the line between thought experiment and reality is getting >> blurry, I want to come back around and spell out the basic facts. >> >> * Yes, making an agent to control WildFly instances to avoid a >> configuration step is theoretically possible. >> * No, it's not a good idea for multiple reasons, and it seems likely >> cause additional problems down the line. >> * Unless we have another fundamental change of architecture, I don't see >> us supporting this approach. >> * We have other, supported ways to solve the same problem (e.g. deploy a >> subsystem, use JMX, use the management API) and tools that can help >> support this approach (e.g. CLI scripting). >> >> -- >> - DML >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From rory.odonnell at oracle.com Fri Mar 24 06:53:55 2017 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 24 Mar 2017 10:53:55 +0000 Subject: [wildfly-dev] JDK 9 EA Build 162 is available on java.net Message-ID: Hi Jason/Tomaz, *JDK 9 Early Access* b162 is available on java.net, summary of changes are listed here . There is one fix for a bug reported by Open Source projects since the last availability email : * b161 - JDK 8176265 Method overload resolution on a covariant base type doesn't work in 9 Other change that maybe of interest: * b162 - JDK 8176503 security-libs Disable SHA-1 TLS Server Certificates *Better tools for adjusting to strong encapsulation -* please read Mark Reinhold's email on this topic [1] * * *Quality Outreach Report for March 2017 *is available [2], many thanks for your continued support and welcome to the new projects! ***Schedule - **JDK 9 Rampdown Phase 2*: Proposal accepted [3]. The overall goal of this process is to ensure that we fix just the bugs that must be fixed in order to ensure a successful release. Oracle's JRE and JDK Cryptographic Roadmap has been updated since last availability email [4] Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-March/011763.html [2] https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+March+2017 [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-March/005689.html [4] https://www.java.com/en/jre-jdk-cryptoroadmap.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170324/d785c0a6/attachment.html From tomaz.cerar at gmail.com Fri Mar 24 11:23:15 2017 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 24 Mar 2017 16:23:15 +0100 Subject: [wildfly-dev] JDK 9 EA Build 162 is available on java.net In-Reply-To: References: Message-ID: Hey Rory, we currently are blocked by compiler bug, that we reported https://bugs.openjdk.java.net/browse/JDK-8177520 We are still testing most of the components with latest jdk9 builds, but WildFly build itself is currently broken. -- tomaz On Fri, Mar 24, 2017 at 11:53 AM, Rory O'Donnell wrote: > Hi Jason/Tomaz, > > *JDK 9 Early Access* b162 is > available on java.net, summary of changes are listed here > . > There is one fix for a bug reported by Open Source projects since the last > availability email : > > - b161 - JDK 8176265 Method overload resolution on a covariant base > type doesn't work in 9 > > Other change that maybe of interest: > > - b162 - JDK 8176503 security-libs Disable SHA-1 TLS Server > Certificates > > > *Better tools for adjusting to strong encapsulation -* please read Mark > Reinhold's email on this topic [1] > > *Quality Outreach Report for March 2017 *is available [2], many thanks > for your continued support > and welcome to the new projects! > > *Schedule - JDK 9 Rampdown Phase 2*: Proposal accepted [3]. > The overall goal of this process is to ensure that we fix just the bugs > that must be fixed in order to ensure a successful release. > > Oracle's JRE and JDK Cryptographic Roadmap has been updated since last > availability email [4] > > Rgds,Rory > > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017- > March/011763.html > [2] https://wiki.openjdk.java.net/display/quality/Quality+ > Outreach+report+March+2017 > [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-March/005689.html > [4] https://www.java.com/en/jre-jdk-cryptoroadmap.html > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170324/33ba5447/attachment.html From ebenzacar at gmail.com Sun Mar 26 09:29:02 2017 From: ebenzacar at gmail.com (Eric B) Date: Sun, 26 Mar 2017 09:29:02 -0400 Subject: [wildfly-dev] How-to create Custom SessionManager and SessionConfig implementations? Message-ID: I've been trying to figure out how to build my own custom SessionManager to push my sessions into Redis with a custom SessionConfig implementation, but am having trouble finding any documentation to that extent. For the SesisonManager, I've read that I need to: 1. Develop SessionManager which implements io.undertow.server.session. SessionManager 2. Develop SessionManagerFactory which implements io.undertow.servlet.api.SessionManagerFactory 3. Develop startup extension which implements io.undertow.servlet.ServletExtension, and in handleDeployment(Deployment) method change sessionManagerFactory with new SessionManagerFactory. 4. Register new ServletExtension by adding ../META-INF/services/io. undertow.servlet.ServletExtension file (file should contain the name of new ServletExtension. for example com.my.utils.StartupExtension) But I can't seem to find anything that indicates how to provide my own SessionConfig implementation. How do I register a custom SessionConfig implementation? Is there any documentation to that extent? Are there any examples that can show me how to create my own SessionManager and SessionConfig object? Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170326/f592c104/attachment-0001.html From smarlow at redhat.com Tue Mar 28 12:32:40 2017 From: smarlow at redhat.com (Scott Marlow) Date: Tue, 28 Mar 2017 12:32:40 -0400 Subject: [wildfly-dev] Could WildFly automatically detect Hibernate native applications and auto add Hibernate dependencies to the application classpath... Message-ID: Hibernate native applications that are deployed on WildFly, need the application classpath to include org.hibernate:main + org.javassist:main static modules. We proposed via WFLY-459 [1], that the Hibernate ORM module should export the javassist module but that is not overrideable by applications (since module exclusions are ignored for export=true modules). Another approach could be adding a (tattletale like?) deployment unit processor to WildFly, that could scan through application classes, without loading them, to check for references to certain Hibernate classes, like "org.hibernate.Session". Would that introduce too much overhead to deployment? If we did this scanning, we would have to scan through all application classes to verify that the application doesn't already depend on a Hibernate static module or include its own copy of Hibernate classes. Perhaps an alternative could be a wildflySomething.xml way to indicate that a deployment is a Hibernate native application and that Hibernate/Javassist dependencies should be auto added. What do you think? Scott [1] https://issues.jboss.org/browse/WFLY-459 From sanne at hibernate.org Tue Mar 28 13:59:07 2017 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 28 Mar 2017 18:59:07 +0100 Subject: [wildfly-dev] Could WildFly automatically detect Hibernate native applications and auto add Hibernate dependencies to the application classpath... In-Reply-To: References: Message-ID: Thanks Scott for reviving the subject. Let me remind that an application wishing to use `org.hibernate:main` without Javassist won't work.. so I don't see why "being able to exclude it" is a realistic use case. On the other hand, moving the "automatic inclusion" currently handled by the JPA subsystem into an explicit dependency of the ORM module allows us to finally get rid of this need for Javassist in the near future. Thanks, Sanne On 28 March 2017 at 17:32, Scott Marlow wrote: > Hibernate native applications that are deployed on WildFly, need the > application classpath to include org.hibernate:main + org.javassist:main > static modules. We proposed via WFLY-459 [1], that the Hibernate ORM > module should export the javassist module but that is not overrideable > by applications (since module exclusions are ignored for export=true > modules). > > Another approach could be adding a (tattletale like?) deployment unit > processor to WildFly, that could scan through application classes, > without loading them, to check for references to certain Hibernate > classes, like "org.hibernate.Session". Would that introduce too much > overhead to deployment? If we did this scanning, we would have to scan > through all application classes to verify that the application doesn't > already depend on a Hibernate static module or include its own copy of > Hibernate classes. > > Perhaps an alternative could be a wildflySomething.xml way to indicate > that a deployment is a Hibernate native application and that > Hibernate/Javassist dependencies should be auto added. > > What do you think? > > Scott > > [1] https://issues.jboss.org/browse/WFLY-459 > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From david.lloyd at redhat.com Tue Mar 28 15:10:40 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 28 Mar 2017 14:10:40 -0500 Subject: [wildfly-dev] Version notifications at library init Message-ID: <047c9328-8163-db71-8a2f-fc2e9e4fba52@redhat.com> This is relatively minor but I've been sitting on it for a pretty long time so I wanted to see if anyone had a strong opinion about it. In the past few years, we've internationalized many of our projects, and in the process assigned unique, searchable codes to exceptions and INFO-and-higher log messages. In the meantime, as part of our existing logging standards, we always log a version string for each library as it is activated (this lets us quickly identify which versions of which libraries are active, in order to aid in troubleshooting, etc.). At present it is not part of our logging standard to assign a searchable code to the version message. It has been suggested that we begin doing so. If we did, I would recommend that the code be '0' for such messages as most if not all of our projects use '1' as the lowest message ID. The advantage of doing so is that it allows a given library's version message to be quickly found in a log file, even if the language of the log file is not known to the searcher. The disadvantage is that it brings in additional noise to the log which makes it harder to read. Does anyone have any strong feelings one way or the other, or better yet, some pros or cons to add? -- - DML From brian.stansberry at redhat.com Tue Mar 28 16:54:32 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 28 Mar 2017 15:54:32 -0500 Subject: [wildfly-dev] Version notifications at library init In-Reply-To: <047c9328-8163-db71-8a2f-fc2e9e4fba52@redhat.com> References: <047c9328-8163-db71-8a2f-fc2e9e4fba52@redhat.com> Message-ID: <84C35613-4B22-4EA8-B919-D30E2923DD13@redhat.com> We already have codes for a lot of these messsages so there?s not much added noise. FWIW I hope we don?t have a standard to log every lib version. We already are way too noisy at boot, IMHO. If someone has a nifty way to write these to the server log but not the console that would be lovely. And I?d like a pony too. ;) > On Mar 28, 2017, at 2:10 PM, David M. Lloyd wrote: > > This is relatively minor but I've been sitting on it for a pretty long > time so I wanted to see if anyone had a strong opinion about it. > > In the past few years, we've internationalized many of our projects, and > in the process assigned unique, searchable codes to exceptions and > INFO-and-higher log messages. In the meantime, as part of our existing > logging standards, we always log a version string for each library as it > is activated (this lets us quickly identify which versions of which > libraries are active, in order to aid in troubleshooting, etc.). > > At present it is not part of our logging standard to assign a searchable > code to the version message. It has been suggested that we begin doing > so. If we did, I would recommend that the code be '0' for such messages > as most if not all of our projects use '1' as the lowest message ID. > > The advantage of doing so is that it allows a given library's version > message to be quickly found in a log file, even if the language of the > log file is not known to the searcher. The disadvantage is that it > brings in additional noise to the log which makes it harder to read. > > Does anyone have any strong feelings one way or the other, or better > yet, some pros or cons to add? > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From david.lloyd at redhat.com Tue Mar 28 17:15:43 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 28 Mar 2017 16:15:43 -0500 Subject: [wildfly-dev] Version notifications at library init In-Reply-To: <84C35613-4B22-4EA8-B919-D30E2923DD13@redhat.com> References: <047c9328-8163-db71-8a2f-fc2e9e4fba52@redhat.com> <84C35613-4B22-4EA8-B919-D30E2923DD13@redhat.com> Message-ID: <79afb900-4011-8d25-1de7-f73768dc2d84@redhat.com> Since 2007 at least [1]. I believe it came from an earlier set of standards which predate my employment with JBoss but that was so long ago that I don't recall for certain. That said, I'm open to revising how we do this as well. The log segregation tools we theoretically have at our disposal are: ? Level ? Category ? NDC ? MDC ? Source class/method/file/line ? Arbitrary filter However, I don't really have any bright ideas as to a *good* way to do this (which is simple and hard for users to break, but also doesn't screw up performance). [1] https://developer.jboss.org/wiki/LoggingStandards/version/2 On 03/28/2017 03:54 PM, Brian Stansberry wrote: > We already have codes for a lot of these messsages so there?s not much added noise. > > FWIW I hope we don?t have a standard to log every lib version. We already are way too noisy at boot, IMHO. If someone has a nifty way to write these to the server log but not the console that would be lovely. And I?d like a pony too. ;) > >> On Mar 28, 2017, at 2:10 PM, David M. Lloyd wrote: >> >> This is relatively minor but I've been sitting on it for a pretty long >> time so I wanted to see if anyone had a strong opinion about it. >> >> In the past few years, we've internationalized many of our projects, and >> in the process assigned unique, searchable codes to exceptions and >> INFO-and-higher log messages. In the meantime, as part of our existing >> logging standards, we always log a version string for each library as it >> is activated (this lets us quickly identify which versions of which >> libraries are active, in order to aid in troubleshooting, etc.). >> >> At present it is not part of our logging standard to assign a searchable >> code to the version message. It has been suggested that we begin doing >> so. If we did, I would recommend that the code be '0' for such messages >> as most if not all of our projects use '1' as the lowest message ID. >> >> The advantage of doing so is that it allows a given library's version >> message to be quickly found in a log file, even if the language of the >> log file is not known to the searcher. The disadvantage is that it >> brings in additional noise to the log which makes it harder to read. >> >> Does anyone have any strong feelings one way or the other, or better >> yet, some pros or cons to add? >> >> -- >> - DML >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML From brian.stansberry at redhat.com Tue Mar 28 17:51:29 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 28 Mar 2017 16:51:29 -0500 Subject: [wildfly-dev] Version notifications at library init In-Reply-To: <79afb900-4011-8d25-1de7-f73768dc2d84@redhat.com> References: <047c9328-8163-db71-8a2f-fc2e9e4fba52@redhat.com> <84C35613-4B22-4EA8-B919-D30E2923DD13@redhat.com> <79afb900-4011-8d25-1de7-f73768dc2d84@redhat.com> Message-ID: Before I never directly addressed your message id 0 point. Sounds good to me. Some existing ids would need to change to comply but that doesn?t seem like a big deal. > On Mar 28, 2017, at 4:15 PM, David M. Lloyd wrote: > > Since 2007 at least [1]. I believe it came from an earlier set of standards which predate my employment with JBoss but that was so long ago that I don't recall for certain. > Thanks; I?d never seen that one. > That said, I'm open to revising how we do this as well. The log segregation tools we theoretically have at our disposal are: > Sorry about derailing your thread! In my defense though, despite my whinging about the log noise, as we move toward Alexey?s more flexible provisioning the utility of these kinds of messages will go up. The relationship of library version to overall server version may be more fluid. So I dislike them now but will probably like them later and we?ll want more. But spamming the *console* with dozens of such messages will also leave a bad impression on users. Big, slow, bloated etc. > ? Level > ? Category We use this now, to get debug output for org.jboss.as.config in the server.log. Seems to work ok, but doing it for versions would mean having some standard log category for these messages. A common category also makes it easy for users to turn this off, which is both a pro and a con. I doubt projects would accept a common category though, as it makes it harder for their users to configure their logging when the project is used elsewhere. > ? NDC > ? MDC > ? Source class/method/file/line > ? Arbitrary filter Another tangent: Do we have a standard for the message code format? There?s a defacto one but I mean a formal one. I know there are efforts going on to make better use of these in search, and having a formal spec I think will be helpful in reliably extracting the code from surrounding text. I believe we could say the codes are required to be 4 or more chars A-Z followed by 3 or more digits, followed by ?: ?. I raise this tangent because if in the version messages the digits are all 0 that?s a pattern that can be filtered on. But I expect that would be quite bad for perf. > > However, I don't really have any bright ideas as to a *good* way to do this (which is simple and hard for users to break, but also doesn't screw up performance). > > [1] https://developer.jboss.org/wiki/LoggingStandards/version/2 > > On 03/28/2017 03:54 PM, Brian Stansberry wrote: >> We already have codes for a lot of these messsages so there?s not much added noise. >> >> FWIW I hope we don?t have a standard to log every lib version. We already are way too noisy at boot, IMHO. If someone has a nifty way to write these to the server log but not the console that would be lovely. And I?d like a pony too. ;) >> >>> On Mar 28, 2017, at 2:10 PM, David M. Lloyd wrote: >>> >>> This is relatively minor but I've been sitting on it for a pretty long >>> time so I wanted to see if anyone had a strong opinion about it. >>> >>> In the past few years, we've internationalized many of our projects, and >>> in the process assigned unique, searchable codes to exceptions and >>> INFO-and-higher log messages. In the meantime, as part of our existing >>> logging standards, we always log a version string for each library as it >>> is activated (this lets us quickly identify which versions of which >>> libraries are active, in order to aid in troubleshooting, etc.). >>> >>> At present it is not part of our logging standard to assign a searchable >>> code to the version message. It has been suggested that we begin doing >>> so. If we did, I would recommend that the code be '0' for such messages >>> as most if not all of our projects use '1' as the lowest message ID. >>> >>> The advantage of doing so is that it allows a given library's version >>> message to be quickly found in a log file, even if the language of the >>> log file is not known to the searcher. The disadvantage is that it >>> brings in additional noise to the log which makes it harder to read. >>> >>> Does anyone have any strong feelings one way or the other, or better >>> yet, some pros or cons to add? >>> >>> -- >>> - DML >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > -- > - DML -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From david.lloyd at redhat.com Tue Mar 28 18:04:12 2017 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 28 Mar 2017 17:04:12 -0500 Subject: [wildfly-dev] Version notifications at library init In-Reply-To: References: <047c9328-8163-db71-8a2f-fc2e9e4fba52@redhat.com> <84C35613-4B22-4EA8-B919-D30E2923DD13@redhat.com> <79afb900-4011-8d25-1de7-f73768dc2d84@redhat.com> Message-ID: On 03/28/2017 04:51 PM, Brian Stansberry wrote: > Before I never directly addressed your message id 0 point. Sounds good to me. Some existing ids would need to change to comply but that doesn?t seem like a big deal. > > On Mar 28, 2017, at 4:15 PM, David M. Lloyd wrote: >> Since 2007 at least [1]. I believe it came from an earlier set of standards which predate my employment with JBoss but that was so long ago that I don't recall for certain. > > Thanks; I?d never seen that one. > >> That said, I'm open to revising how we do this as well. The log segregation tools we theoretically have at our disposal are: > > Sorry about derailing your thread! Nah it's an important (if decidedly unglamorous) topic! > In my defense though, despite my whinging about the log noise, as we move toward Alexey?s more flexible provisioning the utility of these kinds of messages will go up. The relationship of library version to overall server version may be more fluid. So I dislike them now but will probably like them later and we?ll want more. But spamming the *console* with dozens of such messages will also leave a bad impression on users. Big, slow, bloated etc. Makes sense. >> ? Level >> ? Category > > We use this now, to get debug output for org.jboss.as.config in the server.log. Seems to work ok, but doing it for versions would mean having some standard log category for these messages. A common category also makes it easy for users to turn this off, which is both a pro and a con. > > I doubt projects would accept a common category though, as it makes it harder for their users to configure their logging when the project is used elsewhere. Agreed. >> ? NDC >> ? MDC >> ? Source class/method/file/line >> ? Arbitrary filter > > Another tangent: Do we have a standard for the message code format? There?s a defacto one but I mean a formal one. I know there are efforts going on to make better use of these in search, and having a formal spec I think will be helpful in reliably extracting the code from surrounding text. I believe we could say the codes are required to be 4 or more chars A-Z followed by 3 or more digits, followed by ?: ?. I'm pretty sure there is one, but I can't immediately find it. When coming up with it, we discussed various options like "AAAA-####" or "AAAA_####" but decided on "AAAA####" because it would count as a single word from the perspective of web searches. I don't think we formally specified the number of letters or numbers in a doc, nor the ": " suffix. > I raise this tangent because if in the version messages the digits are all 0 that?s a pattern that can be filtered on. But I expect that would be quite bad for perf. Yeah, undoubtedly, in addition to being a bit ugly (obscure special handling) and maybe confusing ("why are some of my messages missing?"). Playing devil's advocate though: INFO messages are fairly infrequent, so at least the perf argument is less relevant if the filter checks the level of the message before anything else. -- - DML From jperkins at redhat.com Tue Mar 28 20:06:17 2017 From: jperkins at redhat.com (James Perkins) Date: Tue, 28 Mar 2017 17:06:17 -0700 Subject: [wildfly-dev] Version notifications at library init In-Reply-To: <79afb900-4011-8d25-1de7-f73768dc2d84@redhat.com> References: <047c9328-8163-db71-8a2f-fc2e9e4fba52@redhat.com> <84C35613-4B22-4EA8-B919-D30E2923DD13@redhat.com> <79afb900-4011-8d25-1de7-f73768dc2d84@redhat.com> Message-ID: We could just ensure that "version" is in the category and use a filter. That requires some buy-in from external dependencies though. I guess really any solution requires some kind of buy-in. On Tue, Mar 28, 2017 at 2:15 PM, David M. Lloyd wrote: > Since 2007 at least [1]. I believe it came from an earlier set of > standards which predate my employment with JBoss but that was so long > ago that I don't recall for certain. > > That said, I'm open to revising how we do this as well. The log > segregation tools we theoretically have at our disposal are: > > ? Level > ? Category > ? NDC > ? MDC > ? Source class/method/file/line > ? Arbitrary filter > > However, I don't really have any bright ideas as to a *good* way to do > this (which is simple and hard for users to break, but also doesn't > screw up performance). > > [1] https://developer.jboss.org/wiki/LoggingStandards/version/2 > > On 03/28/2017 03:54 PM, Brian Stansberry wrote: > > We already have codes for a lot of these messsages so there?s not much > added noise. > > > > FWIW I hope we don?t have a standard to log every lib version. We > already are way too noisy at boot, IMHO. If someone has a nifty way to > write these to the server log but not the console that would be lovely. And > I?d like a pony too. ;) > > > >> On Mar 28, 2017, at 2:10 PM, David M. Lloyd > wrote: > >> > >> This is relatively minor but I've been sitting on it for a pretty long > >> time so I wanted to see if anyone had a strong opinion about it. > >> > >> In the past few years, we've internationalized many of our projects, and > >> in the process assigned unique, searchable codes to exceptions and > >> INFO-and-higher log messages. In the meantime, as part of our existing > >> logging standards, we always log a version string for each library as it > >> is activated (this lets us quickly identify which versions of which > >> libraries are active, in order to aid in troubleshooting, etc.). > >> > >> At present it is not part of our logging standard to assign a searchable > >> code to the version message. It has been suggested that we begin doing > >> so. If we did, I would recommend that the code be '0' for such messages > >> as most if not all of our projects use '1' as the lowest message ID. > >> > >> The advantage of doing so is that it allows a given library's version > >> message to be quickly found in a log file, even if the language of the > >> log file is not known to the searcher. The disadvantage is that it > >> brings in additional noise to the log which makes it harder to read. > >> > >> Does anyone have any strong feelings one way or the other, or better > >> yet, some pros or cons to add? > >> > >> -- > >> - DML > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170328/db51e059/attachment.html From rsvoboda at redhat.com Wed Mar 29 07:44:57 2017 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Wed, 29 Mar 2017 07:44:57 -0400 (EDT) Subject: [wildfly-dev] Version notifications at library init In-Reply-To: References: <047c9328-8163-db71-8a2f-fc2e9e4fba52@redhat.com> <84C35613-4B22-4EA8-B919-D30E2923DD13@redhat.com> <79afb900-4011-8d25-1de7-f73768dc2d84@redhat.com> Message-ID: <776883949.16589109.1490787897418.JavaMail.zimbra@redhat.com> > Some existing ids would need to change to comply but that doesn?t seem like > a big deal. Maybe not for community, but can be trouble for product. Customers are encouraged to parse logs based on message IDs. Rostislav From brian.stansberry at redhat.com Wed Mar 29 07:57:49 2017 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 29 Mar 2017 06:57:49 -0500 Subject: [wildfly-dev] Version notifications at library init In-Reply-To: <776883949.16589109.1490787897418.JavaMail.zimbra@redhat.com> References: <047c9328-8163-db71-8a2f-fc2e9e4fba52@redhat.com> <84C35613-4B22-4EA8-B919-D30E2923DD13@redhat.com> <79afb900-4011-8d25-1de7-f73768dc2d84@redhat.com> <776883949.16589109.1490787897418.JavaMail.zimbra@redhat.com> Message-ID: > On Mar 29, 2017, at 6:44 AM, Rostislav Svoboda wrote: > > >> Some existing ids would need to change to comply but that doesn?t seem like >> a big deal. > > Maybe not for community, but can be trouble for product. Customers are encouraged to parse logs based on message IDs. > I think the likelihood that people are relying on parsing out our version # messages is really low. If they did a convention of reserving 0 for these might be a benefit for them too. Here?s what we log now (standalone-full-ha.xml): 06:49:15,205 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta6 06:49:15,503 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1 06:49:15,638 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 11.0.0.Beta1-SNAPSHOT (WildFly Core 3.0.0.Beta12-SNAPSHOT) starting 06:49:16,987 INFO [org.wildfly.security] (ServerService Thread Pool -- 35) ELY00001: WildFly Elytron version 1.1.0.Beta33 06:49:17,202 INFO [org.xnio] (MSC service thread 1-6) XNIO version 3.5.0.Beta2 06:49:17,208 INFO [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.5.0.Beta2 06:49:17,238 INFO [org.jboss.as.jaxrs] (ServerService Thread Pool -- 49) WFLYRS0016: RESTEasy version 3.0.21.Final 06:49:17,271 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 52) WFLYCLJG0001: Activating JGroups subsystem. JGroups version 3.6.13 06:49:17,392 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Beta1 06:49:17,407 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0003: Undertow 1.4.11.Final starting 06:49:17,409 INFO [org.jboss.as.connector] (MSC service thread 1-8) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.2.Final) 06:49:17,705 INFO [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 5.0.0.Beta19 06:49:18,544 INFO [org.jboss.ws.common.management] (MSC service thread 1-6) JBWS022052: Starting JBossWS 5.1.8.Final (Apache CXF 3.1.10) 8 of those have ids. Perhaps WFLYSRV0049 would be a problem, although the final ?started? message is more likely what would be monitored and it shows the versions too. -- Brian Stansberry Manager, Senior Principal Software Engineer JBoss by Red Hat From ehugonne at redhat.com Wed Mar 29 08:57:59 2017 From: ehugonne at redhat.com (Emmanuel Hugonnet) Date: Wed, 29 Mar 2017 14:57:59 +0200 Subject: [wildfly-dev] Version notifications at library init In-Reply-To: References: <047c9328-8163-db71-8a2f-fc2e9e4fba52@redhat.com> <84C35613-4B22-4EA8-B919-D30E2923DD13@redhat.com> <79afb900-4011-8d25-1de7-f73768dc2d84@redhat.com> <776883949.16589109.1490787897418.JavaMail.zimbra@redhat.com> Message-ID: FYI : I monitor the starting and started message in the netbeans plugin to check that everything is correct and then try to connect when I launch WildFly with nice regexp. Emmanuel Le 29/03/2017 ? 13:57, Brian Stansberry a ?crit : > >> On Mar 29, 2017, at 6:44 AM, Rostislav Svoboda wrote: >> >> >>> Some existing ids would need to change to comply but that doesn?t seem like >>> a big deal. >> >> Maybe not for community, but can be trouble for product. Customers are encouraged to parse logs based on message IDs. >> > > I think the likelihood that people are relying on parsing out our version # messages is really low. If they did a convention of reserving 0 for these might be a benefit for them too. > > Here?s what we log now (standalone-full-ha.xml): > > 06:49:15,205 INFO [org.jboss.modules] (main) JBoss Modules version 1.6.0.Beta6 > 06:49:15,503 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.7.SP1 > 06:49:15,638 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 11.0.0.Beta1-SNAPSHOT (WildFly Core 3.0.0.Beta12-SNAPSHOT) starting > 06:49:16,987 INFO [org.wildfly.security] (ServerService Thread Pool -- 35) ELY00001: WildFly Elytron version 1.1.0.Beta33 > 06:49:17,202 INFO [org.xnio] (MSC service thread 1-6) XNIO version 3.5.0.Beta2 > 06:49:17,208 INFO [org.xnio.nio] (MSC service thread 1-6) XNIO NIO Implementation Version 3.5.0.Beta2 > 06:49:17,238 INFO [org.jboss.as.jaxrs] (ServerService Thread Pool -- 49) WFLYRS0016: RESTEasy version 3.0.21.Final > 06:49:17,271 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 52) WFLYCLJG0001: Activating JGroups subsystem. JGroups version 3.6.13 > 06:49:17,392 INFO [org.jboss.as.security] (MSC service thread 1-1) WFLYSEC0001: Current PicketBox version=5.0.0.Beta1 > 06:49:17,407 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0003: Undertow 1.4.11.Final starting > 06:49:17,409 INFO [org.jboss.as.connector] (MSC service thread 1-8) WFLYJCA0009: Starting JCA Subsystem (WildFly/IronJacamar 1.4.2.Final) > 06:49:17,705 INFO [org.jboss.remoting] (MSC service thread 1-6) JBoss Remoting version 5.0.0.Beta19 > 06:49:18,544 INFO [org.jboss.ws.common.management] (MSC service thread 1-6) JBWS022052: Starting JBossWS 5.1.8.Final (Apache CXF 3.1.10) > > 8 of those have ids. Perhaps WFLYSRV0049 would be a problem, although the final ?started? message is more likely what would be monitored and it shows the versions too. > -------------- 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/20170329/8aa36c2b/attachment.bin From smarlow at redhat.com Wed Mar 29 10:49:32 2017 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 29 Mar 2017 10:49:32 -0400 Subject: [wildfly-dev] Could WildFly automatically detect Hibernate native applications and auto add Hibernate dependencies to the application classpath... In-Reply-To: References: Message-ID: I wonder if it would be possible to integrate the jboss-deployment-structure.xml module exclusion checking, into our modular classloader, so that we could do the exclude when Hibernate ORM exports Javassist? Then, I think that Hibernate ORM could safely export the Javassist module dependency to the application deployment. The next best thing, might be some way to fail the deployment if the application jboss-deployment-structure.xml tries to exclude javassist. On 03/28/2017 01:59 PM, Sanne Grinovero wrote: Thanks Scott for reviving the subject. Let me remind that an application wishing to use `org.hibernate:main` without Javassist won't work.. so I don't see why "being able to exclude it" is a realistic use case. True, users should use the same version of Javassist (with Hibernate), that we include with WildFly (IMO), however, it is still possible that a user could do try to do that. On the other hand, moving the "automatic inclusion" currently handled by the JPA subsystem into an explicit dependency of the ORM module allows us to finally get rid of this need for Javassist in the near future. Thanks, Sanne On 28 March 2017 at 17:32, Scott Marlow wrote: Hibernate native applications that are deployed on WildFly, need the application classpath to include org.hibernate:main + org.javassist:main static modules. We proposed via WFLY-459 [1], that the Hibernate ORM module should export the javassist module but that is not overrideable by applications (since module exclusions are ignored for export=true modules). Another approach could be adding a (tattletale like?) deployment unit processor to WildFly, that could scan through application classes, without loading them, to check for references to certain Hibernate classes, like "org.hibernate.Session". Would that introduce too much overhead to deployment? If we did this scanning, we would have to scan through all application classes to verify that the application doesn't already depend on a Hibernate static module or include its own copy of Hibernate classes. Perhaps an alternative could be a wildflySomething.xml way to indicate that a deployment is a Hibernate native application and that Hibernate/Javassist dependencies should be auto added. What do you think? Scott [1] https://issues.jboss.org/browse/WFLY-459 _______________________________________________ wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20170329/55664c64/attachment-0001.html