From kkhan at redhat.com Fri Nov 2 06:51:42 2018 From: kkhan at redhat.com (Kabir Khan) Date: Fri, 2 Nov 2018 10:51:42 +0000 Subject: [wildfly-dev] Slack? Message-ID: Hi, I want to play a bit with Slack. I see https://wildfly.slack.com is already taken, and that is where it makes most sense to play. If anybody here owns that, can you invite me and make me an admin? Thanks, Kabir -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181102/d59643f5/attachment.html From kkhan at redhat.com Mon Nov 5 04:53:21 2018 From: kkhan at redhat.com (Kabir Khan) Date: Mon, 5 Nov 2018 09:53:21 +0000 Subject: [wildfly-dev] WildFly 15 Feature Freeze Message-ID: Hi all, Just a quick reminder that the WildFly 15 feature freeze is next Wednesday 14 November. After that we will only accept bug fixes until the tag which is planned on 28th November. For WildFly Core RFEs this effectively means the cut-off is the end of this week. Thanks, Kabir -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181105/ccdf3086/attachment.html From mmarusic at redhat.com Thu Nov 8 04:33:35 2018 From: mmarusic at redhat.com (Marek Marusic) Date: Thu, 8 Nov 2018 10:33:35 +0100 Subject: [wildfly-dev] Wildfly cloud operator Message-ID: Hello Everyone, The operator-framework [1] allows to create various operators for cloud. There is already wildfly-operator [1] created with operator-framework [2]. Does this operator cover all needed scenarios needed for cloud or are there any plans to create official Wildfly operator? [1] https://github.com/operator-framework/operator-sdk [2] https://github.com/banzaicloud/wildfly-operator Thank you and wish you a wonderful day, Marek Marek Marusic Associate Software Engineer - JBOSS SET TEAM Red Hat Purky?ova 111, 612 00 Brno mmarusic at redhat.com TRIED. TESTED. TRUSTED. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181108/6948efb6/attachment.html From thofman at redhat.com Thu Nov 8 06:45:26 2018 From: thofman at redhat.com (Tomas Hofman) Date: Thu, 8 Nov 2018 12:45:26 +0100 Subject: [wildfly-dev] Standalone EJB client configuration - maximumConnectedClusterNodes Message-ID: <22253bd8-5b35-11f6-3f29-7cd2d9660b1a@redhat.com> Hi, there's a request to simplify jboss-ejb-client configuration: https://issues.jboss.org/browse/JBEAP-15407 The issue specifically deals with setting "maximumConnectedClusterNodes", which is not possible to set via wildfly-config.xml and neither via jboss-ejb-client.properties. (The old client accepted property "remote.cluster.xxx.max-allowed-connected-nodes" in jboss-ejb-client.properties, but it's not recognized by the current client.) I pointed out in the ticket that setting maximumConnectedClusterNodes is possible via programmatic API, like: EJBClientContext context = new EJBClientContext.Builder() .setMaximumConnectedClusterNodes(5) .addTransportProvider(new RemoteTransportProvider()) .build(); EJBClientContext.getContextManager().setDefault(context); // lookup etc... but Jorg considers that to be a workaround and thinks that "simple property given to the InitialContext should be sufficient". Now to the solutions: 1) I don't think that passing configuration properties directly to the InitialContext is the way we want to support. At least I didn't see that anywhere in current docs, and I didn't see any code (in ejb client) that would provide for that. Correct? 2) I would like to fix current client to again support "remote.cluster.xxx.max-allowed-connected-nodes" in jboss-ejb-client.properties. 3) Is it desirable to extend wildfly-config.xml schema to support more config options? Thanks! -- Tomas Hofman Software Engineer, JBoss SET Red Hat From kwills at redhat.com Thu Nov 8 09:56:13 2018 From: kwills at redhat.com (Ken Wills) Date: Thu, 8 Nov 2018 08:56:13 -0600 Subject: [wildfly-dev] Wildfly cloud operator In-Reply-To: References: Message-ID: Hi Marek, On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic wrote: > Hello Everyone, > > The operator-framework [1] allows to create various operators for cloud. > There is already wildfly-operator > [1] created with > operator-framework [2]. > Does this operator cover all needed scenarios needed for cloud or are > there any plans to create official Wildfly operator? > Thanks for linking this, I hadn't seen it. There is a fair amount of other configuration support that could be provided via operator vs what I see here, but its a good example. (Basically anything you might want to change in the configuration, and I'd tend towards using the CLI vs manipulating the XML directly.) Ken > > [1] https://github.com/operator-framework/operator-sdk > [2] https://github.com/banzaicloud/wildfly-operator > > Thank you and wish you a wonderful day, > Marek > > Marek Marusic > > Associate Software Engineer - JBOSS SET TEAM > > Red Hat > > > > Purky?ova 111, 612 00 Brno > > mmarusic at redhat.com > > TRIED. TESTED. TRUSTED. > _______________________________________________ > 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/20181108/947f80c5/attachment-0001.html From jdenise at redhat.com Fri Nov 9 03:30:17 2018 From: jdenise at redhat.com (Jean-Francois Denise) Date: Fri, 9 Nov 2018 09:30:17 +0100 Subject: [wildfly-dev] Subsystems to advertise implicit and optional dependencies to galleon Message-ID: <683df9a8-3f82-3f9b-dc23-4a4243e16af5@redhat.com> Hi, in the galleon project, in a context where we would not provision a complete server but just a subset required to run a given configuration, we have identified a need for subsystems to advertise to the galleon tooling some modules in addition to the modules galleon discover by traversing the module dependency tree. The first case is DeploymentProcessor injecting modules into the deployment units (implicit modules). The deployment injected ones are not required to be a dependency of the subsystem module, so galleon has the risk to miss some of them. As an example, in logging subsystem we have the following non optional injected modules : "org.jboss.logging", "org.apache.commons.logging", "org.apache.log4j", "org.slf4j", "org.jboss.logging.jul-to-slf4j-stub" Some of these modules are direct dependencies of logging subsystem, some others are indirect dependencies, others could be not present at all in the module dependency tree (eg: org.jboss.logging.jul-to-slf4j-stub). So we are thinking at solving this issue in 2 possible ways: 1) Mandate that all injected modules become dependencies of the subsystem module at the cost to load some useless modules at runtime. 2) Possibly better, make the subsystem to call RuntimeCapability.addAdditionalRequiredPackages (package name being module name) for each injected module. An existing capability or a new one? would have to be created. There is also the case of optional injected module dependencies (eg: ee subsystem org.glassfish.javax.el, org.eclipse.yasson, ...). We need to treat them differently. When one is provisioning a server using galleon he can choose to exclude some packages from the provisioned server. Optional packages can be excluded without making the provisioned state invalid (as opposed to required package that can't be excluded). These optional implicit dependencies are typical usage of this, they are not required by the deployment unit to properly operate. For these, we plan to use RuntimeCapability.addAdditionalOptionalPackages. We can't make them "optional" in JBoss module. When galleon provision a subset of the server we don't include all optional dependencies. This brings the case of provisioning of optional dependencies present in JBOSS module.xml. We have identified multiple kind of optional dependencies. 1) The optional dependencies that are referencing modules only in use when a feature is present in the configuration of the subsystem (eg: jmx subsystem optional dep on org.jboss.remoting-jmx due to , remoting subsystem optional dep on io.undertow.core for , elytron subsystem optional dep on org.picketbox for ) In order to have these dependencies to be provisioned with the subsystem, we can attach thanks to RuntimeCapability.addAdditionalRequiredPackages the modules to the feature. When the feature is present in the configuration, the module is no more optional but required. 2) The optional dependencies that reference modules that are part of another subsystems and only use if this other subsystem is present (eg: org.jboss.as.jpa optional dep on org.jboss.as.ejb3, org.jboss.as.transactions optional dep on org.jboss.remoting). These ones are simply not taken into account 3)? The optional dependencies that reference modules that are not part of another subsystem (so are not provisioned by another source) but are only meaningful if the other subsystem is present. We call these ones "passive" (eg: org.jboss.as.weld optional dependency on org.jboss.as.weld.ejb|jpa|beanvalidation|webservices|transactions). "passive" are analyzed. If all their dependencies are present, then they are included. Some implicit optional dependencies can fall into this category (eg: org.jboss.jaxrs optional dep on org.jboss.resteasy.resteasy-validator-provider-11). The passive optional dependencies would be advertised with RuntimeCapability.addAdditionalPassiveOptionalPackages(optional dependency package name). So to summarize: - RuntimeCapability.addAdditionalRequiredPackages for all required implicit modules - RuntimeCapability.addAdditionalRequiredPackages to associate optional dependencies to a feature - RuntimeCapability.addAdditionalOptionalPackages for all optional implicit dependencies that are not passive - RuntimeCapability.addAdditionalPassiveOptionalPackages for all optional dependencies (implicit or not) that are passive Is it something that subsystems owner would be ready to put in place to help galleon in this task? It would require a bit of analysis of the dependencies of your modules but the gain could be quite important. Some early experimentation of this has shown a big reduction of the server filesystem footprint (web server + cdi has been reduced from 156MB to 46MB). The runtime memory usage reduction is not that big, but less modules being loaded we have a gain. Thanks for reading. JF From rory.odonnell at oracle.com Fri Nov 9 05:27:20 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 9 Nov 2018 10:27:20 +0000 Subject: [wildfly-dev] JDK 12 , JDK 8u202 & Project Panama Early-Access builds available Message-ID: <19357098-c2b1-0df6-c99f-60dda8de84eb@oracle.com> Hi David & Richard,* * *JDK 12 Early Access build 19 is available at : - jdk.java.net/12/* * These early-access, open-source builds are provided under the GNU General Public License, version?2, with the Classpath Exception . * Release Notes updates since last email o Build 18 ? JDK-8211883: Disable anon and NULL cipher suites + Crypto Roadmap Updated o Build 17 ? JDK-8211806: TLS 1.3 handshake server name indication is missing on a session resume o Build 16 ? JDK-8211866: TLS 1.3 CertificateRequest message sometimes offers disallowed signature algorithms o Build 17 ? JDK-8195793 : Remove GTE CyberTrust Global Root o Build 16 - JDK-8191053 : Provide a mechanism to make system's security manager immutable * JEPs proposed for JDK 12 so far: o JEP 230 - Microbenchmark Suite * JEPs targeted to JDK 12, so far o 325: Switch Expressions (Preview) o 326: Raw String Literals (Preview) o 340: One AArch64 Port, Not Two o 341: Default CDS Archives *JDK 8u202 Early Access build 03 is available at : - **http://jdk.java.net/8/* * JDK 8u202 timeline is available [1] o GA is scheduled for January 2019 *Project Panama Early-Access build 0 ***is available at : - http://jdk.java.net/panama/ ** * Early access builds from Project Panama * Early-access builds are provided under the GNU General Public License, version?2, with the Classpath Exception . * Feedback - Please send feedback via e-mail to panama-dev at openjdk.java.net . * To send e-mail to this address you must first subscribe to the mailing list . *Crypto Roadmap Updated [2] * Rgds,Rory [1] http://openjdk.java.net/projects/jdk8u/releases/8u202.html [2] https://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/20181109/5ecd3852/attachment.html From brian.stansberry at redhat.com Fri Nov 9 12:32:57 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 9 Nov 2018 11:32:57 -0600 Subject: [wildfly-dev] Subsystems to advertise implicit and optional dependencies to galleon In-Reply-To: <683df9a8-3f82-3f9b-dc23-4a4243e16af5@redhat.com> References: <683df9a8-3f82-3f9b-dc23-4a4243e16af5@redhat.com> Message-ID: On Fri, Nov 9, 2018 at 2:30 AM, Jean-Francois Denise wrote: > Hi, > > in the galleon project, in a context where we would not provision a > complete server but just a subset required to run a given configuration, > we have identified a need for subsystems to advertise to the galleon > tooling some modules in addition to the modules galleon discover by > traversing the module dependency tree. > > The first case is DeploymentProcessor injecting modules into the > deployment units (implicit modules). > > The deployment injected ones are not required to be a dependency of the > subsystem module, so galleon has the risk to miss some of them. > > As an example, in logging subsystem we have the following non optional > injected modules : > "org.jboss.logging", > "org.apache.commons.logging", > "org.apache.log4j", > "org.slf4j", > "org.jboss.logging.jul-to-slf4j-stub" > > Some of these modules are direct dependencies of logging subsystem, some > others are indirect dependencies, others could be not present at all in > the module dependency tree (eg: org.jboss.logging.jul-to-slf4j-stub). > > So we are thinking at solving this issue in 2 possible ways: > > 1) Mandate that all injected modules become dependencies of the > subsystem module at the cost to load some useless modules at runtime. > > 2) Possibly better, make the subsystem to call > RuntimeCapability.addAdditionalRequiredPackages (package name being > module name) for each injected module. An existing capability or a new > one would have to be created. > > There is also the case of optional injected module dependencies (eg: ee > subsystem org.glassfish.javax.el, org.eclipse.yasson, ...). We need to > treat them differently. When one is provisioning a server using galleon > he can choose to exclude some packages from the provisioned server. > Optional packages can be excluded without making the provisioned state > invalid (as opposed to required package that can't be excluded). These > optional implicit dependencies are typical usage of this, they are not > required by the deployment unit to properly operate. > > For these, we plan to use > RuntimeCapability.addAdditionalOptionalPackages. We can't make them > "optional" in JBoss module. When galleon provision a subset of the > server we don't include all optional dependencies. > > This brings the case of provisioning of optional dependencies present in > JBOSS module.xml. > > We have identified multiple kind of optional dependencies. > > 1) The optional dependencies that are referencing modules only in use > when a feature is present in the configuration of the subsystem (eg: jmx > subsystem optional dep on org.jboss.remoting-jmx due to > , remoting subsystem optional dep on > io.undertow.core for , elytron subsystem optional dep > on org.picketbox for ) > > In order to have these dependencies to be provisioned with the > subsystem, we can attach thanks to > RuntimeCapability.addAdditionalRequiredPackages the modules to the > feature. When the feature is present in the configuration, the module is > no more optional but required. > > 2) The optional dependencies that reference modules that are part of > another subsystems and only use if this other subsystem is present (eg: > org.jboss.as.jpa optional dep on org.jboss.as.ejb3, > org.jboss.as.transactions optional dep on org.jboss.remoting). These > ones are simply not taken into account > > 3) The optional dependencies that reference modules that are not part > of another subsystem (so are not provisioned by another source) but are > only meaningful if the other subsystem is present. We call these ones > "passive" (eg: org.jboss.as.weld optional dependency on > org.jboss.as.weld.ejb|jpa|beanvalidation|webservices|transactions). > "passive" are analyzed. If all their dependencies are present, then they > are included. Some implicit optional dependencies can fall into this > category (eg: org.jboss.jaxrs optional dep on > org.jboss.resteasy.resteasy-validator-provider-11). > > The passive optional dependencies would be advertised with > RuntimeCapability.addAdditionalPassiveOptionalPackages(optional > dependency package name). > > So to summarize: > > - RuntimeCapability.addAdditionalRequiredPackages for all required > implicit modules > > - RuntimeCapability.addAdditionalRequiredPackages to associate optional > dependencies to a feature > > - RuntimeCapability.addAdditionalOptionalPackages for all optional > implicit dependencies that are not passive > > - RuntimeCapability.addAdditionalPassiveOptionalPackages for all > optional dependencies (implicit or not) that are passive > A good question Alexey raised is whether the capability is the right concept for encapsulating this information. In the end the key point is that the information ends up in the galleon feature-spec. That's the thing that encapsulates the configuration elements and the packages (i.e. fs content) that are needed to provide a feature. It's the feature that needs the package. We generate the galleon feature specs from our management model information. When in WF 13 we hit the first must-implement use case for getting additional package info into a feature spec I kind of arbitrarily picked 'RuntimeCapability' as the place to record that. It was a reasonable enough choice for that one use case but isn't great otherwise. The alternative is to record this data in the ResourceDefinition, which is the primary source of the data that's used in the feature spec generation. The conceptual argument is a capability is all about a named provider of a contract that other elements of the server can rely on; e.g. some MSC Service with a particular value type that will be exposed. But this additional package stuff isn't really about that contract, it's about other things that will be done that likely are not relevant to other elements of the system. A hint of a design smell would be if we end up creating RuntimeCapability instances for no other reason than to record this additional package information. Something I could see happening with this logging case you mentioned at the start. I don't think ResourceDefinition has this problem. > Is it something that subsystems owner would be ready to put in place to > help galleon in this task? It would require a bit of analysis of the > dependencies of your modules but the gain could be quite important. Please don't let my point above derail consideration of this question. Use of ResourceDefinition vs RuntimeCapability is a relatively small detail. Some > early experimentation of this has shown a big reduction of the server > filesystem footprint (web server + cdi has been reduced from 156MB to > 46MB). The runtime memory usage reduction is not that big, but less > modules being loaded we have a gain. > > Thanks for reading. > > JF > > _______________________________________________ > 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 Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181109/56c24359/attachment-0001.html From jperkins at redhat.com Fri Nov 9 13:45:00 2018 From: jperkins at redhat.com (James Perkins) Date: Fri, 9 Nov 2018 10:45:00 -0800 Subject: [wildfly-dev] Subsystems to advertise implicit and optional dependencies to galleon In-Reply-To: <683df9a8-3f82-3f9b-dc23-4a4243e16af5@redhat.com> References: <683df9a8-3f82-3f9b-dc23-4a4243e16af5@redhat.com> Message-ID: The main reason those modules are dependencies of the logging subsystem is because they are not really required for the subsystem itself with the exception of org.jboss.logging. Those module dependencies are added to deployments for convenience. So really they're not required at all unless the user is using one of those logging frameworks and they want the logging subsystem to control the logging output. This may be somewhat of an edge case because if the user doesn't use, say slf4j, then there is no real reason to include the dependency unless of course another module uses it. I do wonder if we should remove the org.jboss.logging.jul-to-slf4j-stub module and just put the library as a resource root to org.slf4j, but that's slightly OT :) On Fri, Nov 9, 2018 at 12:34 AM Jean-Francois Denise wrote: > Hi, > > in the galleon project, in a context where we would not provision a > complete server but just a subset required to run a given configuration, > we have identified a need for subsystems to advertise to the galleon > tooling some modules in addition to the modules galleon discover by > traversing the module dependency tree. > > The first case is DeploymentProcessor injecting modules into the > deployment units (implicit modules). > > The deployment injected ones are not required to be a dependency of the > subsystem module, so galleon has the risk to miss some of them. > > As an example, in logging subsystem we have the following non optional > injected modules : > "org.jboss.logging", > "org.apache.commons.logging", > "org.apache.log4j", > "org.slf4j", > "org.jboss.logging.jul-to-slf4j-stub" > > Some of these modules are direct dependencies of logging subsystem, some > others are indirect dependencies, others could be not present at all in > the module dependency tree (eg: org.jboss.logging.jul-to-slf4j-stub). > > So we are thinking at solving this issue in 2 possible ways: > > 1) Mandate that all injected modules become dependencies of the > subsystem module at the cost to load some useless modules at runtime. > > 2) Possibly better, make the subsystem to call > RuntimeCapability.addAdditionalRequiredPackages (package name being > module name) for each injected module. An existing capability or a new > one would have to be created. > > There is also the case of optional injected module dependencies (eg: ee > subsystem org.glassfish.javax.el, org.eclipse.yasson, ...). We need to > treat them differently. When one is provisioning a server using galleon > he can choose to exclude some packages from the provisioned server. > Optional packages can be excluded without making the provisioned state > invalid (as opposed to required package that can't be excluded). These > optional implicit dependencies are typical usage of this, they are not > required by the deployment unit to properly operate. > > For these, we plan to use > RuntimeCapability.addAdditionalOptionalPackages. We can't make them > "optional" in JBoss module. When galleon provision a subset of the > server we don't include all optional dependencies. > > This brings the case of provisioning of optional dependencies present in > JBOSS module.xml. > > We have identified multiple kind of optional dependencies. > > 1) The optional dependencies that are referencing modules only in use > when a feature is present in the configuration of the subsystem (eg: jmx > subsystem optional dep on org.jboss.remoting-jmx due to > , remoting subsystem optional dep on > io.undertow.core for , elytron subsystem optional dep > on org.picketbox for ) > > In order to have these dependencies to be provisioned with the > subsystem, we can attach thanks to > RuntimeCapability.addAdditionalRequiredPackages the modules to the > feature. When the feature is present in the configuration, the module is > no more optional but required. > > 2) The optional dependencies that reference modules that are part of > another subsystems and only use if this other subsystem is present (eg: > org.jboss.as.jpa optional dep on org.jboss.as.ejb3, > org.jboss.as.transactions optional dep on org.jboss.remoting). These > ones are simply not taken into account > > 3) The optional dependencies that reference modules that are not part > of another subsystem (so are not provisioned by another source) but are > only meaningful if the other subsystem is present. We call these ones > "passive" (eg: org.jboss.as.weld optional dependency on > org.jboss.as.weld.ejb|jpa|beanvalidation|webservices|transactions). > "passive" are analyzed. If all their dependencies are present, then they > are included. Some implicit optional dependencies can fall into this > category (eg: org.jboss.jaxrs optional dep on > org.jboss.resteasy.resteasy-validator-provider-11). > > The passive optional dependencies would be advertised with > RuntimeCapability.addAdditionalPassiveOptionalPackages(optional > dependency package name). > > So to summarize: > > - RuntimeCapability.addAdditionalRequiredPackages for all required > implicit modules > > - RuntimeCapability.addAdditionalRequiredPackages to associate optional > dependencies to a feature > > - RuntimeCapability.addAdditionalOptionalPackages for all optional > implicit dependencies that are not passive > > - RuntimeCapability.addAdditionalPassiveOptionalPackages for all > optional dependencies (implicit or not) that are passive > > Is it something that subsystems owner would be ready to put in place to > help galleon in this task? It would require a bit of analysis of the > dependencies of your modules but the gain could be quite important. Some > early experimentation of this has shown a big reduction of the server > filesystem footprint (web server + cdi has been reduced from 156MB to > 46MB). The runtime memory usage reduction is not that big, but less > modules being loaded we have a gain. > > Thanks for reading. > > JF > > _______________________________________________ > 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/20181109/e486976c/attachment.html From brian.stansberry at redhat.com Sat Nov 10 17:44:05 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Sat, 10 Nov 2018 16:44:05 -0600 Subject: [wildfly-dev] Subsystems to advertise implicit and optional dependencies to galleon In-Reply-To: References: <683df9a8-3f82-3f9b-dc23-4a4243e16af5@redhat.com> Message-ID: On Fri, Nov 9, 2018 at 12:45 PM, James Perkins wrote: > The main reason those modules are dependencies of the logging subsystem is > because they are not really required for the subsystem itself with the > exception of org.jboss.logging. Those module dependencies are added to > deployments for convenience. So really they're not required at all unless > the user is using one of those logging frameworks and they want the logging > subsystem to control the logging output. > So this is this case from Jean-Francois' initial post: "- RuntimeCapability.addAdditionalOptionalPackages for all optional implicit dependencies that are not passive" (Note that it's only truly optional if the DUP registers it that way.) If the logging subsystem doesn't actual use the module itself then it's module.xml would not record it as a dependency. This is the right thing to do regardless if the logging subsystem isn't accessing any resources from them. > This may be somewhat of an edge case because if the user doesn't use, say > slf4j, then there is no real reason to include the dependency unless of > course another module uses it. > AIUI the idea is that by not including these in the logging subsystem module.xml but instead recording them in the management model definition via addAdditionalOptionalPackages, this information will end up in the galleon feature spec. Based on that galleon will provision the modules, but would allow the user to exclude them if they wanted to further optimize. I assume that for compatibility reasons we must provision them by default. I do wonder if we should remove the org.jboss.logging.jul-to-slf4j-stub > module and just put the library as a resource root to org.slf4j, but that's > slightly OT :) > > On Fri, Nov 9, 2018 at 12:34 AM Jean-Francois Denise > wrote: > >> Hi, >> >> in the galleon project, in a context where we would not provision a >> complete server but just a subset required to run a given configuration, >> we have identified a need for subsystems to advertise to the galleon >> tooling some modules in addition to the modules galleon discover by >> traversing the module dependency tree. >> >> The first case is DeploymentProcessor injecting modules into the >> deployment units (implicit modules). >> >> The deployment injected ones are not required to be a dependency of the >> subsystem module, so galleon has the risk to miss some of them. >> >> As an example, in logging subsystem we have the following non optional >> injected modules : >> "org.jboss.logging", >> "org.apache.commons.logging", >> "org.apache.log4j", >> "org.slf4j", >> "org.jboss.logging.jul-to-slf4j-stub" >> >> Some of these modules are direct dependencies of logging subsystem, some >> others are indirect dependencies, others could be not present at all in >> the module dependency tree (eg: org.jboss.logging.jul-to-slf4j-stub). >> >> So we are thinking at solving this issue in 2 possible ways: >> >> 1) Mandate that all injected modules become dependencies of the >> subsystem module at the cost to load some useless modules at runtime. >> >> 2) Possibly better, make the subsystem to call >> RuntimeCapability.addAdditionalRequiredPackages (package name being >> module name) for each injected module. An existing capability or a new >> one would have to be created. >> >> There is also the case of optional injected module dependencies (eg: ee >> subsystem org.glassfish.javax.el, org.eclipse.yasson, ...). We need to >> treat them differently. When one is provisioning a server using galleon >> he can choose to exclude some packages from the provisioned server. >> Optional packages can be excluded without making the provisioned state >> invalid (as opposed to required package that can't be excluded). These >> optional implicit dependencies are typical usage of this, they are not >> required by the deployment unit to properly operate. >> >> For these, we plan to use >> RuntimeCapability.addAdditionalOptionalPackages. We can't make them >> "optional" in JBoss module. When galleon provision a subset of the >> server we don't include all optional dependencies. >> >> This brings the case of provisioning of optional dependencies present in >> JBOSS module.xml. >> >> We have identified multiple kind of optional dependencies. >> >> 1) The optional dependencies that are referencing modules only in use >> when a feature is present in the configuration of the subsystem (eg: jmx >> subsystem optional dep on org.jboss.remoting-jmx due to >> , remoting subsystem optional dep on >> io.undertow.core for , elytron subsystem optional dep >> on org.picketbox for ) >> >> In order to have these dependencies to be provisioned with the >> subsystem, we can attach thanks to >> RuntimeCapability.addAdditionalRequiredPackages the modules to the >> feature. When the feature is present in the configuration, the module is >> no more optional but required. >> >> 2) The optional dependencies that reference modules that are part of >> another subsystems and only use if this other subsystem is present (eg: >> org.jboss.as.jpa optional dep on org.jboss.as.ejb3, >> org.jboss.as.transactions optional dep on org.jboss.remoting). These >> ones are simply not taken into account >> >> 3) The optional dependencies that reference modules that are not part >> of another subsystem (so are not provisioned by another source) but are >> only meaningful if the other subsystem is present. We call these ones >> "passive" (eg: org.jboss.as.weld optional dependency on >> org.jboss.as.weld.ejb|jpa|beanvalidation|webservices|transactions). >> "passive" are analyzed. If all their dependencies are present, then they >> are included. Some implicit optional dependencies can fall into this >> category (eg: org.jboss.jaxrs optional dep on >> org.jboss.resteasy.resteasy-validator-provider-11). >> >> The passive optional dependencies would be advertised with >> RuntimeCapability.addAdditionalPassiveOptionalPackages(optional >> dependency package name). >> >> So to summarize: >> >> - RuntimeCapability.addAdditionalRequiredPackages for all required >> implicit modules >> >> - RuntimeCapability.addAdditionalRequiredPackages to associate optional >> dependencies to a feature >> >> - RuntimeCapability.addAdditionalOptionalPackages for all optional >> implicit dependencies that are not passive >> >> - RuntimeCapability.addAdditionalPassiveOptionalPackages for all >> optional dependencies (implicit or not) that are passive >> >> Is it something that subsystems owner would be ready to put in place to >> help galleon in this task? It would require a bit of analysis of the >> dependencies of your modules but the gain could be quite important. Some >> early experimentation of this has shown a big reduction of the server >> filesystem footprint (web server + cdi has been reduced from 156MB to >> 46MB). The runtime memory usage reduction is not that big, but less >> modules being loaded we have a gain. >> >> Thanks for reading. >> >> JF >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > James R. Perkins > JBoss by Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181110/1deafff5/attachment-0001.html From jdenise at redhat.com Mon Nov 12 06:46:35 2018 From: jdenise at redhat.com (Jean-Francois Denise) Date: Mon, 12 Nov 2018 12:46:35 +0100 Subject: [wildfly-dev] Subsystems to advertise implicit and optional dependencies to galleon In-Reply-To: References: <683df9a8-3f82-3f9b-dc23-4a4243e16af5@redhat.com> Message-ID: <7c01bc58-7d12-d6cb-806f-0d3ef4c894b5@redhat.com> Thank-you. On 09/11/2018 19:45, James Perkins wrote: > The main reason those modules are dependencies of the logging > subsystem is because they are not really required for the subsystem > itself with the exception of org.jboss.logging. Those module > dependencies are added to deployments for convenience. So really > they're not required at all unless the user is using one of those > logging frameworks and they want the logging subsystem to control the > logging output. There is some logic to attempt to load the module, if it succeeds, then the dependency is added as a required one. Could this be replaced by an optional dependency and no module loading? These modules would have to to be added thanks to addAdditionalOptionalPackages. > > This may be somewhat of an edge case because if the user doesn't use, > say slf4j, then there is no real reason to include the dependency > unless of course another module uses it. I do wonder if we should > remove the org.jboss.logging.jul-to-slf4j-stub module and just put the > library as a resource root to org.slf4j, but that's slightly OT :) > > On Fri, Nov 9, 2018 at 12:34 AM Jean-Francois Denise > > wrote: > > Hi, > > in the galleon project, in a context where we would not provision a > complete server but just a subset required to run a given > configuration, > we have identified a need for subsystems to advertise to the galleon > tooling some modules in addition to the modules galleon discover by > traversing the module dependency tree. > > The first case is DeploymentProcessor injecting modules into the > deployment units (implicit modules). > > The deployment injected ones are not required to be a dependency > of the > subsystem module, so galleon has the risk to miss some of them. > > As an example, in logging subsystem we have the following non > optional > injected modules : > "org.jboss.logging", > "org.apache.commons.logging", > "org.apache.log4j", > "org.slf4j", > "org.jboss.logging.jul-to-slf4j-stub" > > Some of these modules are direct dependencies of logging > subsystem, some > others are indirect dependencies, others could be not present at > all in > the module dependency tree (eg: org.jboss.logging.jul-to-slf4j-stub). > > So we are thinking at solving this issue in 2 possible ways: > > 1) Mandate that all injected modules become dependencies of the > subsystem module at the cost to load some useless modules at runtime. > > 2) Possibly better, make the subsystem to call > RuntimeCapability.addAdditionalRequiredPackages (package name being > module name) for each injected module. An existing capability or a > new > one? would have to be created. > > There is also the case of optional injected module dependencies > (eg: ee > subsystem org.glassfish.javax.el, org.eclipse.yasson, ...). We > need to > treat them differently. When one is provisioning a server using > galleon > he can choose to exclude some packages from the provisioned server. > Optional packages can be excluded without making the provisioned > state > invalid (as opposed to required package that can't be excluded). > These > optional implicit dependencies are typical usage of this, they are > not > required by the deployment unit to properly operate. > > For these, we plan to use > RuntimeCapability.addAdditionalOptionalPackages. We can't make them > "optional" in JBoss module. When galleon provision a subset of the > server we don't include all optional dependencies. > > This brings the case of provisioning of optional dependencies > present in > JBOSS module.xml. > > We have identified multiple kind of optional dependencies. > > 1) The optional dependencies that are referencing modules only in use > when a feature is present in the configuration of the subsystem > (eg: jmx > subsystem optional dep on org.jboss.remoting-jmx due to > , remoting subsystem optional dep on > io.undertow.core for , elytron subsystem optional > dep > on org.picketbox for ) > > In order to have these dependencies to be provisioned with the > subsystem, we can attach thanks to > RuntimeCapability.addAdditionalRequiredPackages the modules to the > feature. When the feature is present in the configuration, the > module is > no more optional but required. > > 2) The optional dependencies that reference modules that are part of > another subsystems and only use if this other subsystem is present > (eg: > org.jboss.as.jpa optional dep on org.jboss.as.ejb3, > org.jboss.as.transactions optional dep on org.jboss.remoting). These > ones are simply not taken into account > > 3)? The optional dependencies that reference modules that are not > part > of another subsystem (so are not provisioned by another source) > but are > only meaningful if the other subsystem is present. We call these ones > "passive" (eg: org.jboss.as.weld optional dependency on > org.jboss.as.weld.ejb|jpa|beanvalidation|webservices|transactions). > "passive" are analyzed. If all their dependencies are present, > then they > are included. Some implicit optional dependencies can fall into this > category (eg: org.jboss.jaxrs optional dep on > org.jboss.resteasy.resteasy-validator-provider-11). > > The passive optional dependencies would be advertised with > RuntimeCapability.addAdditionalPassiveOptionalPackages(optional > dependency package name). > > So to summarize: > > - RuntimeCapability.addAdditionalRequiredPackages for all required > implicit modules > > - RuntimeCapability.addAdditionalRequiredPackages to associate > optional > dependencies to a feature > > - RuntimeCapability.addAdditionalOptionalPackages for all optional > implicit dependencies that are not passive > > - RuntimeCapability.addAdditionalPassiveOptionalPackages for all > optional dependencies (implicit or not) that are passive > > Is it something that subsystems owner would be ready to put in > place to > help galleon in this task? It would require a bit of analysis of the > dependencies of your modules but the gain could be quite > important. Some > early experimentation of this has shown a big reduction of the server > filesystem footprint (web server + cdi has been reduced from 156MB to > 46MB). The runtime memory usage reduction is not that big, but less > modules being loaded we have a gain. > > Thanks for reading. > > JF > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > James R. Perkins > JBoss by Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181112/5051f09f/attachment.html From jdenise at redhat.com Mon Nov 12 08:28:09 2018 From: jdenise at redhat.com (Jean-Francois Denise) Date: Mon, 12 Nov 2018 14:28:09 +0100 Subject: [wildfly-dev] Subsystems to advertise implicit and optional dependencies to galleon In-Reply-To: References: <683df9a8-3f82-3f9b-dc23-4a4243e16af5@redhat.com> Message-ID: On 09/11/2018 18:32, Brian Stansberry wrote: > > > On Fri, Nov 9, 2018 at 2:30 AM, Jean-Francois Denise > > wrote: > > Hi, > > in the galleon project, in a context where we would not provision a > complete server but just a subset required to run a given > configuration, > we have identified a need for subsystems to advertise to the galleon > tooling some modules in addition to the modules galleon discover by > traversing the module dependency tree. > > The first case is DeploymentProcessor injecting modules into the > deployment units (implicit modules). > > The deployment injected ones are not required to be a dependency > of the > subsystem module, so galleon has the risk to miss some of them. > > As an example, in logging subsystem we have the following non > optional > injected modules : > "org.jboss.logging", > "org.apache.commons.logging", > "org.apache.log4j", > "org.slf4j", > "org.jboss.logging.jul-to-slf4j-stub" > > Some of these modules are direct dependencies of logging > subsystem, some > others are indirect dependencies, others could be not present at > all in > the module dependency tree (eg: org.jboss.logging.jul-to-slf4j-stub). > > So we are thinking at solving this issue in 2 possible ways: > > 1) Mandate that all injected modules become dependencies of the > subsystem module at the cost to load some useless modules at runtime. > > 2) Possibly better, make the subsystem to call > RuntimeCapability.addAdditionalRequiredPackages (package name being > module name) for each injected module. An existing capability or a > new > one? would have to be created. > > There is also the case of optional injected module dependencies > (eg: ee > subsystem org.glassfish.javax.el, org.eclipse.yasson, ...). We > need to > treat them differently. When one is provisioning a server using > galleon > he can choose to exclude some packages from the provisioned server. > Optional packages can be excluded without making the provisioned > state > invalid (as opposed to required package that can't be excluded). > These > optional implicit dependencies are typical usage of this, they are > not > required by the deployment unit to properly operate. > > For these, we plan to use > RuntimeCapability.addAdditionalOptionalPackages. We can't make them > "optional" in JBoss module. When galleon provision a subset of the > server we don't include all optional dependencies. > > This brings the case of provisioning of optional dependencies > present in > JBOSS module.xml. > > We have identified multiple kind of optional dependencies. > > 1) The optional dependencies that are referencing modules only in use > when a feature is present in the configuration of the subsystem > (eg: jmx > subsystem optional dep on org.jboss.remoting-jmx due to > , remoting subsystem optional dep on > io.undertow.core for , elytron subsystem optional > dep > on org.picketbox for ) > > In order to have these dependencies to be provisioned with the > subsystem, we can attach thanks to > RuntimeCapability.addAdditionalRequiredPackages the modules to the > feature. When the feature is present in the configuration, the > module is > no more optional but required. > > 2) The optional dependencies that reference modules that are part of > another subsystems and only use if this other subsystem is present > (eg: > org.jboss.as.jpa optional dep on org.jboss.as.ejb3, > org.jboss.as.transactions optional dep on org.jboss.remoting). These > ones are simply not taken into account > > 3)? The optional dependencies that reference modules that are not > part > of another subsystem (so are not provisioned by another source) > but are > only meaningful if the other subsystem is present. We call these ones > "passive" (eg: org.jboss.as.weld optional dependency on > org.jboss.as.weld.ejb|jpa|beanvalidation|webservices|transactions). > "passive" are analyzed. If all their dependencies are present, > then they > are included. Some implicit optional dependencies can fall into this > category (eg: org.jboss.jaxrs optional dep on > org.jboss.resteasy.resteasy-validator-provider-11). > > The passive optional dependencies would be advertised with > RuntimeCapability.addAdditionalPassiveOptionalPackages(optional > dependency package name). > > So to summarize: > > - RuntimeCapability.addAdditionalRequiredPackages for all required > implicit modules > > - RuntimeCapability.addAdditionalRequiredPackages to associate > optional > dependencies to a feature > > - RuntimeCapability.addAdditionalOptionalPackages for all optional > implicit dependencies that are not passive > > - RuntimeCapability.addAdditionalPassiveOptionalPackages for all > optional dependencies (implicit or not) that are passive > > > A good question Alexey raised is whether the capability is the right > concept for encapsulating this information. > > In the end the key point is that the information ends up in the > galleon feature-spec. That's the thing that encapsulates the > configuration elements and the packages (i.e. fs content) that are > needed to provide a feature. It's the feature that needs the package. > We generate the galleon feature specs from our management model > information. When in WF 13 we hit the first must-implement use case > for getting additional package info into a feature spec I kind of > arbitrarily picked 'RuntimeCapability' as the place to record that. It > was a reasonable enough choice for that one use case but isn't great > otherwise. > > The alternative is to record this data in the ResourceDefinition, > which is the primary source of the data that's used in the feature > spec generation. > > The conceptual argument is a capability is all about a named provider > of a contract that other elements of the server can rely on; e.g. some > MSC Service with a particular value type that will be exposed.? But > this additional package stuff isn't really about that contract, it's > about other things that will be done that likely are not relevant to > other elements of the system. > > A hint of a design smell would be if we end up creating > RuntimeCapability instances for no other reason than to record this > additional package information. Something I could see happening with > this logging case you mentioned at the start. > > I don't think ResourceDefinition has this problem. I have introduced artificial capabilities in ee, jaxrs and weld (subsystems that are targeted by the demo) to add additional packages. It seems that it would be common case. So it is actually smelly. > > > Is it something that subsystems owner would be ready to put in > place to > help galleon in this task? It would require a bit of analysis of the > dependencies of your modules but the gain could be quite important. > > > Please don't let my point above derail consideration of this > question.? Use of ResourceDefinition vs RuntimeCapability is a > relatively small detail. > > Some > early experimentation of this has shown a big reduction of the server > filesystem footprint (web server + cdi has been reduced from 156MB to > 46MB). The runtime memory usage reduction is not that big, but less > modules being loaded we have a gain. > > Thanks for reading. > > JF > > _______________________________________________ > 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 > Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181112/84f3d663/attachment-0001.html From ebenzacar at gmail.com Mon Nov 12 09:56:47 2018 From: ebenzacar at gmail.com (Eric B) Date: Mon, 12 Nov 2018 09:56:47 -0500 Subject: [wildfly-dev] WELD/CDI event clarifications Message-ID: I apologize if this not the correct forum to post this question, but I tried looking at the Weld forums and everything appears dormant (even the link to the user's forum is 404 on the Weld site). So I suspected this would be the second best place to ask for some clarity. I'm trying to understand the sequencing of CDI events vs bean initialization. I'm currently concentrating on CDI 1.2/Weld 2.3.5, but figure that this information will be applicable to CDI2.0 as well. I've tried finding documentation online and posting on StackOverflow and neither have produced any results. Specifically, I am confused about the sequencing of CDI events vs when/how bean methods are called. Given what I have read, the following are the events that are triggered by the CDI container: - BeforeBeanDiscovery - ProcessAnnotatedType and ProcessSyntheticAnnotatedType - AfterTypeDiscovery - ProcessInjectionTarget and ProcessProducer - ProcessInjectionPoint - ProcessBeanAttributes - ProcessBean, ProcessManagedBean, ProcessSessionBean, ProcessProducerMethod and ProcessProducerField - ProcessObserverMethod - AfterBeanDiscovery - AfterDeploymentValidation - BeforeShutdown Given these events, when are the events which produce @Initialized(ApplicationScoped.class) and @Destroyer(ApplicationScoped.class) triggered? In which part of the lifecycle? Are they triggered in the @PostConstruct equivalent of the Scoping bean (what is the bean backing the ApplicationScope? I cannot find the implementation in the Weld core - am I even looking in the right place?)? Which brings me to the next question - in which stage of the container setup are the @PostConstruct methods on the beans called? Are they called in the `AfterDeploymentValidation` phase? Or is it somewhat asynchronous - in that the @PostConstruct of an ApplicationScoped bean will be called only when initialized; and that could happen during any of the stages? From what I understand, the BeanManager.getReference() is not allowed prior to the AfterDeploymentValidation event being fired, which to me would imply that beans can only be instantiated (and therefore @PostConstruct'ed) after the `AfterDeploymentValidation` phase. Can anyone direct me towards some clarification of these points? I've tried reading the CDI 1.2 user guide ( https://docs.jboss.org/cdi/learn/userguide/CDI-user-guide.html), but that hasn't provided the details I am looking for. Additionally, I've tried reading through the Weld code but can't find the answers I'm looking for. Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181112/d4accb23/attachment.html From mkouba at redhat.com Mon Nov 12 10:40:09 2018 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 12 Nov 2018 16:40:09 +0100 Subject: [wildfly-dev] WELD/CDI event clarifications In-Reply-To: References: Message-ID: <138b21fa-6c53-698b-6662-48177c09d530@redhat.com> Hi Eric, Weld forum is indeed inaccessible. I don't know what the problem is but we'll try to make it work ASAP. Anyway, there are other channels mentioned on the weld site [1]. WRT your questions - I added few comments inline. HTH Martin [1] weld/user on Gitter #weld-dev IRC channel hosted on freenode.net weld-dev mailing list - https://lists.jboss.org/mailman/listinfo/weld-dev Dne 12. 11. 18 v 15:56 Eric B napsal(a): > I apologize if this not the correct forum to post this question, but I > tried looking at the Weld forums and everything appears dormant (even > the link to the user's forum is 404 on the Weld site).? So I suspected > this would be the second best place to ask for some clarity. > > I'm trying to understand the sequencing of CDI events vs bean > initialization.? I'm currently concentrating on CDI 1.2/Weld 2.3.5, but > figure that this information will be applicable to CDI2.0 as well. > ?I've tried finding documentation online and posting on StackOverflow > and neither have produced any results.? Specifically, I am confused > about the sequencing of CDI events vs when/how bean methods are called. > Given what I have read, the following are the events that are triggered > by the CDI container: > > * BeforeBeanDiscovery > * ProcessAnnotatedType and ProcessSyntheticAnnotatedType > * AfterTypeDiscovery > * ProcessInjectionTarget and ProcessProducer > * ProcessInjectionPoint > * ProcessBeanAttributes > * ProcessBean, ProcessManagedBean, ProcessSessionBean, > ProcessProducerMethod and ProcessProducerField > * ProcessObserverMethod > * AfterBeanDiscovery > * AfterDeploymentValidation > * BeforeShutdown These are container lifecycle events that can be observed on CDI extensions only and the contract is well described in the spec: http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#initialization > > Given these events, when are the events which produce > @Initialized(ApplicationScoped.class) > and?@Destroyer(ApplicationScoped.class) triggered? @Initialized/@Destroyed(/@Predestroyed in 2.0) are regular events that can be observed by regular beans. For example @Initialized(ApplicationScoped.class) events are fired once the application context is initialized. Now "when is @Initialized(ApplicationScoped.class) fired?" - this is a little bit more complicated. It depends on the target runtime (WildFly, Weld SE, Tomcat, ...) and the deployment structure (WAR, EJB, etc.). E.g. in WildFly, for beans located in a WAR the event payload is ServletContext and is fired during ServletContextListener#contextInitialized() notification. For other types of archives (EJB etc.) the event payload is java.lang.Object and is fired after the Weld container is fully initialized. In SE, the event is fired after the WeldContainer is initialized. > In which part of the > lifecycle?? Are they triggered in the @PostConstruct equivalent of the > Scoping bean (what is the bean backing the ApplicationScope?? I cannot > find the implementation in the Weld core - am I even looking in the > right place?)? I'm not sure what you mean here. A @PostConstruct callback is invoked after a contextual instance has been constructed and dependency injection on that instance has been completed, but before this instance is put into service. So if you declare an @Initialized(ApplicationScoped.class) observer on a bean the observer is always notified after the @PostConstruct callback. > > Which brings me to the next question - in which stage of the container > setup are the?@PostConstruct methods on the beans called?? Are they > called in the `AfterDeploymentValidation` phase? No. @PostConstruct callbacks are invoked once a contextual instance is created. Contextual instances are created lazily, on demand. This means that @PostConstruct callbacks are called anytime after AfterDeploymentValidation event is fired but before the application shuts down. > Or is it somewhat > asynchronous - in that the?@PostConstruct of an ApplicationScoped bean > will be called only when initialized; and that could happen during any > of the stages?? From what I understand, the BeanManager.getReference() > is not allowed prior to the AfterDeploymentValidation event being fired, > which to me would imply that beans can only be instantiated (and > therefore?@PostConstruct'ed) after the `AfterDeploymentValidation` phase. > > Can anyone direct me towards some clarification of these points?? I've > tried reading the CDI 1.2 user guide > (https://docs.jboss.org/cdi/learn/userguide/CDI-user-guide.html), but > that hasn't provided the details I am looking for.? Additionally, I've > tried reading through the Weld code but can't find the answers I'm > looking for. > > Thanks, > > Eric > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From jperkins at redhat.com Mon Nov 12 11:27:11 2018 From: jperkins at redhat.com (James Perkins) Date: Mon, 12 Nov 2018 08:27:11 -0800 Subject: [wildfly-dev] Subsystems to advertise implicit and optional dependencies to galleon In-Reply-To: <7c01bc58-7d12-d6cb-806f-0d3ef4c894b5@redhat.com> References: <683df9a8-3f82-3f9b-dc23-4a4243e16af5@redhat.com> <7c01bc58-7d12-d6cb-806f-0d3ef4c894b5@redhat.com> Message-ID: On Mon, Nov 12, 2018 at 3:54 AM Jean-Francois Denise wrote: > Thank-you. > > On 09/11/2018 19:45, James Perkins wrote: > > The main reason those modules are dependencies of the logging subsystem is > because they are not really required for the subsystem itself with the > exception of org.jboss.logging. Those module dependencies are added to > deployments for convenience. So really they're not required at all unless > the user is using one of those logging frameworks and they want the logging > subsystem to control the logging output. > > There is some logic to attempt to load the module, if it succeeds, then > the dependency is added as a required one. Could this be replaced by an > optional dependency and no module loading? These modules would have to to > be added thanks to addAdditionalOptionalPackages. > I guess it really does make sense to have them as optional dependencies in the module.xml. Using the addAddtionalOptionalPackages would work too though. I'd be good with doing it either way so which ever makes the most sense for Galleon. > > This may be somewhat of an edge case because if the user doesn't use, say > slf4j, then there is no real reason to include the dependency unless of > course another module uses it. I do wonder if we should remove the > org.jboss.logging.jul-to-slf4j-stub module and just put the library as a > resource root to org.slf4j, but that's slightly OT :) > > > -- > James R. Perkins > JBoss by Red Hat > > > _______________________________________________ > wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181112/a8044d03/attachment.html From brian.stansberry at redhat.com Mon Nov 12 11:56:11 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 12 Nov 2018 10:56:11 -0600 Subject: [wildfly-dev] Subsystems to advertise implicit and optional dependencies to galleon In-Reply-To: References: <683df9a8-3f82-3f9b-dc23-4a4243e16af5@redhat.com> Message-ID: On Mon, Nov 12, 2018 at 7:28 AM, Jean-Francois Denise wrote: > > > On 09/11/2018 18:32, Brian Stansberry wrote: > > > > On Fri, Nov 9, 2018 at 2:30 AM, Jean-Francois Denise > wrote: > >> Hi, >> >> in the galleon project, in a context where we would not provision a >> complete server but just a subset required to run a given configuration, >> we have identified a need for subsystems to advertise to the galleon >> tooling some modules in addition to the modules galleon discover by >> traversing the module dependency tree. >> >> The first case is DeploymentProcessor injecting modules into the >> deployment units (implicit modules). >> >> The deployment injected ones are not required to be a dependency of the >> subsystem module, so galleon has the risk to miss some of them. >> >> As an example, in logging subsystem we have the following non optional >> injected modules : >> "org.jboss.logging", >> "org.apache.commons.logging", >> "org.apache.log4j", >> "org.slf4j", >> "org.jboss.logging.jul-to-slf4j-stub" >> >> Some of these modules are direct dependencies of logging subsystem, some >> others are indirect dependencies, others could be not present at all in >> the module dependency tree (eg: org.jboss.logging.jul-to-slf4j-stub). >> >> So we are thinking at solving this issue in 2 possible ways: >> >> 1) Mandate that all injected modules become dependencies of the >> subsystem module at the cost to load some useless modules at runtime. >> >> 2) Possibly better, make the subsystem to call >> RuntimeCapability.addAdditionalRequiredPackages (package name being >> module name) for each injected module. An existing capability or a new >> one would have to be created. >> >> There is also the case of optional injected module dependencies (eg: ee >> subsystem org.glassfish.javax.el, org.eclipse.yasson, ...). We need to >> treat them differently. When one is provisioning a server using galleon >> he can choose to exclude some packages from the provisioned server. >> Optional packages can be excluded without making the provisioned state >> invalid (as opposed to required package that can't be excluded). These >> optional implicit dependencies are typical usage of this, they are not >> required by the deployment unit to properly operate. >> >> For these, we plan to use >> RuntimeCapability.addAdditionalOptionalPackages. We can't make them >> "optional" in JBoss module. When galleon provision a subset of the >> server we don't include all optional dependencies. >> >> This brings the case of provisioning of optional dependencies present in >> JBOSS module.xml. >> >> We have identified multiple kind of optional dependencies. >> >> 1) The optional dependencies that are referencing modules only in use >> when a feature is present in the configuration of the subsystem (eg: jmx >> subsystem optional dep on org.jboss.remoting-jmx due to >> , remoting subsystem optional dep on >> io.undertow.core for , elytron subsystem optional dep >> on org.picketbox for ) >> >> In order to have these dependencies to be provisioned with the >> subsystem, we can attach thanks to >> RuntimeCapability.addAdditionalRequiredPackages the modules to the >> feature. When the feature is present in the configuration, the module is >> no more optional but required. >> >> 2) The optional dependencies that reference modules that are part of >> another subsystems and only use if this other subsystem is present (eg: >> org.jboss.as.jpa optional dep on org.jboss.as.ejb3, >> org.jboss.as.transactions optional dep on org.jboss.remoting). These >> ones are simply not taken into account >> >> 3) The optional dependencies that reference modules that are not part >> of another subsystem (so are not provisioned by another source) but are >> only meaningful if the other subsystem is present. We call these ones >> "passive" (eg: org.jboss.as.weld optional dependency on >> org.jboss.as.weld.ejb|jpa|beanvalidation|webservices|transactions). >> "passive" are analyzed. If all their dependencies are present, then they >> are included. Some implicit optional dependencies can fall into this >> category (eg: org.jboss.jaxrs optional dep on >> org.jboss.resteasy.resteasy-validator-provider-11). >> >> The passive optional dependencies would be advertised with >> RuntimeCapability.addAdditionalPassiveOptionalPackages(optional >> dependency package name). >> >> So to summarize: >> >> - RuntimeCapability.addAdditionalRequiredPackages for all required >> implicit modules >> >> - RuntimeCapability.addAdditionalRequiredPackages to associate optional >> dependencies to a feature >> >> - RuntimeCapability.addAdditionalOptionalPackages for all optional >> implicit dependencies that are not passive >> >> - RuntimeCapability.addAdditionalPassiveOptionalPackages for all >> optional dependencies (implicit or not) that are passive >> > > A good question Alexey raised is whether the capability is the right > concept for encapsulating this information. > > In the end the key point is that the information ends up in the galleon > feature-spec. That's the thing that encapsulates the configuration elements > and the packages (i.e. fs content) that are needed to provide a feature. > It's the feature that needs the package. We generate the galleon feature > specs from our management model information. When in WF 13 we hit the first > must-implement use case for getting additional package info into a feature > spec I kind of arbitrarily picked 'RuntimeCapability' as the place to > record that. It was a reasonable enough choice for that one use case but > isn't great otherwise. > > The alternative is to record this data in the ResourceDefinition, which is > the primary source of the data that's used in the feature spec generation. > > The conceptual argument is a capability is all about a named provider of a > contract that other elements of the server can rely on; e.g. some MSC > Service with a particular value type that will be exposed. But this > additional package stuff isn't really about that contract, it's about other > things that will be done that likely are not relevant to other elements of > the system. > > A hint of a design smell would be if we end up creating RuntimeCapability > instances for no other reason than to record this additional package > information. Something I could see happening with this logging case you > mentioned at the start. > > I don't think ResourceDefinition has this problem. > > I have introduced artificial capabilities in ee, jaxrs and weld > (subsystems that are targeted by the demo) to add additional packages. It > seems that it would be common case. So it is actually smelly. > Note though that all 3 of those subsystems are lacking capabilities for things they provide that other subsystems use. Or perhaps in the jaxrs case a private one that lets it require/use capabilities from other subsystems. (Yeray is working on weld.) IOW it's possible you're not really adding artificial capabilities, you're just bumping into the missing ones. ;) ^^^ is just an FYI comment though. I have little doubt we'll find artificial capabilities and it's possible ee, jaxrs, weld would have them. > > > >> Is it something that subsystems owner would be ready to put in place to >> help galleon in this task? It would require a bit of analysis of the >> dependencies of your modules but the gain could be quite important. > > > Please don't let my point above derail consideration of this question. > Use of ResourceDefinition vs RuntimeCapability is a relatively small > detail. > > Some >> early experimentation of this has shown a big reduction of the server >> filesystem footprint (web server + cdi has been reduced from 156MB to >> 46MB). The runtime memory usage reduction is not that big, but less >> modules being loaded we have a gain. >> >> Thanks for reading. >> >> JF >> >> _______________________________________________ >> 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 > Red Hat > > > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181112/a0bad18d/attachment-0001.html From jcosta at redhat.com Tue Nov 13 06:28:22 2018 From: jcosta at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Tue, 13 Nov 2018 12:28:22 +0100 Subject: [wildfly-dev] Can't build wildfly-core master Message-ID: Hey there, I'm preparing a PR for WFLY-10919 and it involves doing some changes to wildfly-core. When trying to build it, though, I get the some errors, either in the tests or compilation errors. I'm following the readme and running a plain `./mvnw install`. I'm on Fedora 29 and OpenJDK 1.8.0_191. This is the full log for `./mvnw install`: https://paste.fedoraproject.org/paste/q4xGSRv31Y-nd5EvvqkPDQ And this is for `./mvnw install -DskipTests`: https://paste.fedoraproject.org/paste/GcKXGqNDM-bbltJx0CfOVg What am I doing wrong? - Juca. From jmesnil at redhat.com Tue Nov 13 08:31:58 2018 From: jmesnil at redhat.com (Jean-Frederic Mesnil) Date: Tue, 13 Nov 2018 14:31:58 +0100 Subject: [wildfly-dev] Can't build wildfly-core master In-Reply-To: References: Message-ID: Hi Juraci, > I'm preparing a PR for WFLY-10919 and it involves doing some changes to > wildfly-core. When trying to build it, though, I get the some errors, > either in the tests or compilation errors. > > I'm following the readme and running a plain `./mvnw install`. I'm on > Fedora 29 and OpenJDK 1.8.0_191. I tried on master and I could not reproduce it. $ java -version java version "1.8.0_181" Java(TM) SE Runtime Environment (build 1.8.0_181-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode) $ ./mvnw install Downloading https://repo1.maven.org/maven2/org/apache/maven/apache-maven/3.3.9/apache-maven-3.3.9-bin.zip ? INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ???????????????????????????????????? My JDK is a bit older than you, I?ll update and check if that works. Jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From jperkins at redhat.com Tue Nov 13 10:22:25 2018 From: jperkins at redhat.com (James Perkins) Date: Tue, 13 Nov 2018 07:22:25 -0800 Subject: [wildfly-dev] Can't build wildfly-core master In-Reply-To: References: Message-ID: Hi Juca, I'm not sure what the issue could be. It seems to be working fine for me on the same setup. I did however do ./mvnw clean install -DskipTests. That said I usually just use my local install of Maven anyway :) On Tue, Nov 13, 2018 at 3:29 AM Juraci Paix?o Kr?hling wrote: > Hey there, > > I'm preparing a PR for WFLY-10919 and it involves doing some changes to > wildfly-core. When trying to build it, though, I get the some errors, > either in the tests or compilation errors. > > I'm following the readme and running a plain `./mvnw install`. I'm on > Fedora 29 and OpenJDK 1.8.0_191. > > This is the full log for `./mvnw install`: > https://paste.fedoraproject.org/paste/q4xGSRv31Y-nd5EvvqkPDQ > > And this is for `./mvnw install -DskipTests`: > https://paste.fedoraproject.org/paste/GcKXGqNDM-bbltJx0CfOVg > > What am I doing wrong? > > - Juca. > _______________________________________________ > 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/20181113/945fbd51/attachment.html From jcosta at redhat.com Tue Nov 13 11:26:43 2018 From: jcosta at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Tue, 13 Nov 2018 17:26:43 +0100 Subject: [wildfly-dev] Can't build wildfly-core master In-Reply-To: References: Message-ID: <18b216be-d6a3-280b-31b2-bae9da4bc3a5@redhat.com> Thanks for the confirmation. I guess I'm just not that used to Maven anymore: wiping out my ~/.m2/repo did the trick - Juca. On 11/13/18 4:22 PM, James Perkins wrote: > Hi Juca, > I'm not sure what the issue could be. It seems to be working fine for me > on the same setup. I did however do ./mvnw clean install -DskipTests. > That said I usually just use my local install of Maven anyway :) > > On Tue, Nov 13, 2018 at 3:29 AM Juraci Paix?o Kr?hling > > wrote: > > Hey there, > > I'm preparing a PR for WFLY-10919 and it involves doing some changes to > wildfly-core. When trying to build it, though, I get the some errors, > either in the tests or compilation errors. > > I'm following the readme and running a plain `./mvnw install`. I'm on > Fedora 29 and OpenJDK 1.8.0_191. > > This is the full log for `./mvnw install`: > https://paste.fedoraproject.org/paste/q4xGSRv31Y-nd5EvvqkPDQ > > And this is for `./mvnw install -DskipTests`: > https://paste.fedoraproject.org/paste/GcKXGqNDM-bbltJx0CfOVg > > What am I doing wrong? > > - Juca. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > James R. Perkins > JBoss by Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From sam.thomas at broadcom.com Tue Nov 13 21:16:01 2018 From: sam.thomas at broadcom.com (Sam Thomas) Date: Wed, 14 Nov 2018 07:46:01 +0530 Subject: [wildfly-dev] -Xbootclasspath/p:jboss-logmanager-.jar equivalent during runtime Message-ID: Hi, I understand when starting jboss you can supply the above to specify the logmanager. If this is not supplied during start up and an agent connects to jboss during runtime using agentmain(), how can I replicate the -Xbootclasspath/p: behavior during runtime? Thanks and Regards Sam Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181114/fd22b526/attachment.html From nikola.malenic at netsetglobal.rs Wed Nov 14 04:50:50 2018 From: nikola.malenic at netsetglobal.rs (Nikola Malenic) Date: Wed, 14 Nov 2018 10:50:50 +0100 Subject: [wildfly-dev] Elytron 4.0 (Wildfly 14) Message-ID: <004301d47bff$86e49030$94adb090$@netsetglobal.rs> Is it possible to put only root CA's certificate in the server truststore and to let users authenticate with certificates signed by this CA? Currently, it throws an error when it tries to bind decoded user principal to the alias in truststore, which has only CA's certificate. I suppose this is possible, but is there any easy(detailed) tutorial on this since I'm not familiar with the whole architecture of the Elytron, and documentation is pretty modest? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181114/dbfde4fa/attachment.html From mchoma at redhat.com Wed Nov 14 09:29:56 2018 From: mchoma at redhat.com (Martin Choma) Date: Wed, 14 Nov 2018 15:29:56 +0100 Subject: [wildfly-dev] Elytron 4.0 (Wildfly 14) In-Reply-To: <004301d47bff$86e49030$94adb090$@netsetglobal.rs> References: <004301d47bff$86e49030$94adb090$@netsetglobal.rs> Message-ID: Best place to ask this question is on forum [1]. This mailing list is for WildFly developers discussions. Anyway, I think you are looking for feature documented by [2] [1] https://developer.jboss.org/en/wildfly/content [2] https://issues.jboss.org/browse/WFLY-10553 On Wed, Nov 14, 2018 at 10:50 AM, Nikola Malenic wrote: > Is it possible to put only root CA?s certificate in the server truststore > and to let users authenticate with certificates signed by this CA? > > Currently, it throws an error when it tries to bind decoded user principal > to the alias in truststore, which has only CA?s certificate. > > > > I suppose this is possible, but is there any easy(detailed) tutorial on this > since I?m not familiar with the whole architecture of the Elytron, and > documentation is pretty modest? > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From ochaloup at redhat.com Wed Nov 14 11:00:34 2018 From: ochaloup at redhat.com (Ondra Chaloupka) Date: Wed, 14 Nov 2018 17:00:34 +0100 Subject: [wildfly-dev] Wildfly cloud operator In-Reply-To: References: Message-ID: Hi, First I have to admit I don't have first hand experience with operators but I would like to add my point of view here. The readme says it's an operator which provides way to startup WildFly server in k8s clustered with kubeping protocol and creating an ingress resource to allow inbound connection from outside world[1]. It let you define your standalone.xml to start with and define deployment to run in the container. The code talks the same[2]. The creator of the operator is a company[3] providing cloud based solution so I expect they take what is the best suiting for the customers - aka. creating a java web application and deploy it easily to WildFly on k8s. As I participate on the WildFly transaction integration for OpenShift[2] I would like highlight that the operator miss for example the logic for handling reliable transaction recovery[4]. And other settings that is offered by cct_modules[5]. Ondra [1] https://github.com/banzaicloud/wildfly-operator/blob/master/README.md [2] https://github.com/banzaicloud/wildfly-operator/blob/master/pkg/stub/handler.go#L37 [3] https://banzaicloud.com/ [4] https://issues.jboss.org/browse/CLOUD-2261 [5] https://github.com/jboss-openshift/cct_module On Thu, Nov 8, 2018 at 4:03 PM Ken Wills wrote: > Hi Marek, > > On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic wrote: > >> Hello Everyone, >> >> The operator-framework [1] allows to create various operators for cloud. >> There is already wildfly-operator >> [1] created with >> operator-framework [2]. >> Does this operator cover all needed scenarios needed for cloud or are >> there any plans to create official Wildfly operator? >> > > Thanks for linking this, I hadn't seen it. There is a fair amount of other > configuration support that could be provided via operator vs what I see > here, but its a good example. (Basically anything you might want to change > in the configuration, and I'd tend towards using the CLI vs manipulating > the XML directly.) > > Ken > > >> >> [1] https://github.com/operator-framework/operator-sdk >> [2] https://github.com/banzaicloud/wildfly-operator >> >> Thank you and wish you a wonderful day, >> Marek >> >> Marek Marusic >> >> Associate Software Engineer - JBOSS SET TEAM >> >> Red Hat >> >> >> >> Purky?ova 111, 612 00 Brno >> >> mmarusic at redhat.com >> >> TRIED. TESTED. TRUSTED. >> _______________________________________________ >> 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/20181114/0fcb4eb9/attachment-0001.html From tom.jenkinson at redhat.com Wed Nov 14 11:51:50 2018 From: tom.jenkinson at redhat.com (Tom Jenkinson) Date: Wed, 14 Nov 2018 16:51:50 +0000 Subject: [wildfly-dev] Wildfly cloud operator In-Reply-To: References: Message-ID: It would also miss the highlighting general lack of EJB remoting and JTS support for transaction propagation. I guess there are other restrictions and guidance for WFLY that might exist. On 14 November 2018 at 16:00, Ondra Chaloupka wrote: > Hi, > > First I have to admit I don't have first hand experience with operators > but I would like to add my point of view here. > > The readme says it's an operator which provides way to startup WildFly > server in k8s clustered with kubeping protocol and creating an ingress > resource to allow inbound connection from outside world[1]. It let you > define your standalone.xml to start with and define deployment to run in > the container. The code talks the same[2]. The creator of the operator is a > company[3] providing cloud based solution so I expect they take what is the > best suiting for the customers - aka. creating a java web application and > deploy it easily to WildFly on k8s. > > As I participate on the WildFly transaction integration for OpenShift[2] I > would like highlight that the operator miss for example the logic for > handling reliable transaction recovery[4]. And other settings that is > offered by cct_modules[5]. > > Ondra > > [1] https://github.com/banzaicloud/wildfly-operator/blob/master/README.md > [2] https://github.com/banzaicloud/wildfly-operator/ > blob/master/pkg/stub/handler.go#L37 > [3] https://banzaicloud.com/ > [4] https://issues.jboss.org/browse/CLOUD-2261 > [5] https://github.com/jboss-openshift/cct_module > > On Thu, Nov 8, 2018 at 4:03 PM Ken Wills wrote: > >> Hi Marek, >> >> On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic wrote: >> >>> Hello Everyone, >>> >>> The operator-framework [1] allows to create various operators for cloud. >>> There is already wildfly-operator >>> [1] created with >>> operator-framework [2]. >>> Does this operator cover all needed scenarios needed for cloud or are >>> there any plans to create official Wildfly operator? >>> >> >> Thanks for linking this, I hadn't seen it. There is a fair amount of >> other configuration support that could be provided via operator vs what I >> see here, but its a good example. (Basically anything you might want to >> change in the configuration, and I'd tend towards using the CLI vs >> manipulating the XML directly.) >> >> Ken >> >> >>> >>> [1] https://github.com/operator-framework/operator-sdk >>> [2] https://github.com/banzaicloud/wildfly-operator >>> >>> Thank you and wish you a wonderful day, >>> Marek >>> >>> Marek Marusic >>> >>> Associate Software Engineer - JBOSS SET TEAM >>> >>> Red Hat >>> >>> >>> >>> Purky?ova 111, 612 00 Brno >>> >>> >>> mmarusic at redhat.com >>> >>> TRIED. TESTED. TRUSTED. >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181114/925f886c/attachment.html From smarlow at redhat.com Wed Nov 14 12:34:34 2018 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 14 Nov 2018 12:34:34 -0500 Subject: [wildfly-dev] JPA container and IronJacamar Synchronizations are registered using org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry but the Hibernate ORM Synchronizations are registered via org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper Message-ID: <170ceb59-6b77-19e2-1b95-29364f01ee36@redhat.com> Hi, I made a local change to JCAOrderedLastSynchronizationList, to have the JPA container (TransactionUtil$SessionSynchronization) afterCompletion() always be run after Hibernate afterCompletion() but before the JCA afterCompletion(). As I am implementing EntityManager caching [1] and want to ensure that the EntityManager instances are only returned to the cache after the EntityManager is expected to be available for reuse. In my debugging, I noticed that the JCAOrderedLastSynchronizationList only has the Hibernate synchronizations being added but not the JCA or JPA container synchronizations. [2] shows that the JCA + JPA Synchronizations are registered via org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry and Hibernate ORM Synchronization is registered via the org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper Should org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry be changed to use JCAOrderedLastSynchronizationList as well, so that IronJacamar (JCA) Synchronizations are run in the correct order? Should we change the JPA subsystem/container to also ensure that Hibernate ORM 5.3 uses the ContextTransactionSynchronizationRegistry instead of the org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper? Is there a WildFly service that represents the org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry lifecycle? The JPA persistence unit service (or global JPA service) should depend on that service, so that applications undeploy if the TSR is stopped. [3] is also related to the the [1] effort and would be impacted by the above mentioned changes. Scott [1] EntityManager caching https://issues.jboss.org/browse/WFLY-11233 [2] https://paste.fedoraproject.org/paste/-wHaYB3mzR2yTXTfU3LbZA [3] Ensure that Hibernate uses direct reference to TSR for better performance https://issues.jboss.org/browse/WFLY-11243 From brian.stansberry at redhat.com Wed Nov 14 12:52:06 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 14 Nov 2018 11:52:06 -0600 Subject: [wildfly-dev] Wildfly cloud operator In-Reply-To: References: Message-ID: Sorry for neglecting to reply to this thread. At some point I'd like to do a WildFly operator, but TBH I'm not sure when we'll get to it. On Wed, Nov 14, 2018 at 11:28 AM Tom Jenkinson wrote: > It would also miss the highlighting general lack of EJB remoting and JTS > support for transaction propagation. > > I guess there are other restrictions and guidance for WFLY that might > exist. > > On 14 November 2018 at 16:00, Ondra Chaloupka wrote: > >> Hi, >> >> First I have to admit I don't have first hand experience with operators >> but I would like to add my point of view here. >> >> The readme says it's an operator which provides way to startup WildFly >> server in k8s clustered with kubeping protocol and creating an ingress >> resource to allow inbound connection from outside world[1]. It let you >> define your standalone.xml to start with and define deployment to run in >> the container. The code talks the same[2]. The creator of the operator is a >> company[3] providing cloud based solution so I expect they take what is the >> best suiting for the customers - aka. creating a java web application and >> deploy it easily to WildFly on k8s. >> >> As I participate on the WildFly transaction integration for OpenShift[2] >> I would like highlight that the operator miss for example the logic for >> handling reliable transaction recovery[4]. And other settings that is >> offered by cct_modules[5]. >> >> Ondra >> >> [1] https://github.com/banzaicloud/wildfly-operator/blob/master/README.md >> [2] >> https://github.com/banzaicloud/wildfly-operator/blob/master/pkg/stub/handler.go#L37 >> [3] https://banzaicloud.com/ >> [4] https://issues.jboss.org/browse/CLOUD-2261 >> [5] https://github.com/jboss-openshift/cct_module >> >> On Thu, Nov 8, 2018 at 4:03 PM Ken Wills wrote: >> >>> Hi Marek, >>> >>> On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic >>> wrote: >>> >>>> Hello Everyone, >>>> >>>> The operator-framework [1] allows to create various operators for cloud. >>>> There is already wildfly-operator >>>> [1] created with >>>> operator-framework [2]. >>>> Does this operator cover all needed scenarios needed for cloud or are >>>> there any plans to create official Wildfly operator? >>>> >>> >>> Thanks for linking this, I hadn't seen it. There is a fair amount of >>> other configuration support that could be provided via operator vs what I >>> see here, but its a good example. (Basically anything you might want to >>> change in the configuration, and I'd tend towards using the CLI vs >>> manipulating the XML directly.) >>> >>> Ken >>> >>> >>>> >>>> [1] https://github.com/operator-framework/operator-sdk >>>> [2] https://github.com/banzaicloud/wildfly-operator >>>> >>>> Thank you and wish you a wonderful day, >>>> Marek >>>> >>>> Marek Marusic >>>> >>>> Associate Software Engineer - JBOSS SET TEAM >>>> >>>> Red Hat >>>> >>>> >>>> >>>> Purky?ova 111, 612 00 Brno >>>> >>>> >>>> mmarusic at redhat.com >>>> >>>> TRIED. TESTED. TRUSTED. >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > _______________________________________________ > 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 Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181114/bed4673d/attachment-0001.html From jperkins at redhat.com Wed Nov 14 13:07:57 2018 From: jperkins at redhat.com (James Perkins) Date: Wed, 14 Nov 2018 10:07:57 -0800 Subject: [wildfly-dev] -Xbootclasspath/p:jboss-logmanager-.jar equivalent during runtime In-Reply-To: References: Message-ID: I'm not sure I follow. The only time the log manager is required to be on the boot class path is if the agent creates a logger before the java.util.logging.LogManager is configured. On Tue, Nov 13, 2018 at 6:17 PM Sam Thomas wrote: > Hi, > > I understand when starting jboss you can supply the above to specify the > logmanager. If this is not supplied during start up and an agent connects > to jboss during runtime using agentmain(), how can I replicate the > -Xbootclasspath/p: behavior during runtime? > > Thanks and Regards > Sam Thomas > _______________________________________________ > 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/20181114/68d37387/attachment.html From tom.jenkinson at redhat.com Wed Nov 14 16:51:34 2018 From: tom.jenkinson at redhat.com (Tom Jenkinson) Date: Wed, 14 Nov 2018 21:51:34 +0000 Subject: [wildfly-dev] JPA container and IronJacamar Synchronizations are registered using org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry but the Hibernate ORM Synchronizations are registered via org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper In-Reply-To: <170ceb59-6b77-19e2-1b95-29364f01ee36@redhat.com> References: <170ceb59-6b77-19e2-1b95-29364f01ee36@redhat.com> Message-ID: The JCAOrderedLastSynchronizationList is intended to guarnatee the ordering in the JVM so it seems very likely it should be used. I wonder why the wrapper is not being injected into JPA and JCA? On 14 November 2018 at 17:34, Scott Marlow wrote: > Hi, > > I made a local change to JCAOrderedLastSynchronizationList, to have the > JPA container (TransactionUtil$SessionSynchronization) afterCompletion() > always be run after Hibernate afterCompletion() but before the JCA > afterCompletion(). As I am implementing EntityManager caching [1] and > want to ensure that the EntityManager instances are only returned to the > cache after the EntityManager is expected to be available for reuse. > > In my debugging, I noticed that the JCAOrderedLastSynchronizationList > only has the Hibernate synchronizations being added but not the JCA or > JPA container synchronizations. [2] shows that the JCA + JPA > Synchronizations are registered via > org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry > and Hibernate ORM Synchronization is registered via the > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegi > stryWrapper > > Should > org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry > be changed to use JCAOrderedLastSynchronizationList as well, so that > IronJacamar (JCA) Synchronizations are run in the correct order? > > Should we change the JPA subsystem/container to also ensure that > Hibernate ORM 5.3 uses the ContextTransactionSynchronizationRegistry > instead of the > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper? > > > > Is there a WildFly service that represents the > org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry > lifecycle? The JPA persistence unit service (or global JPA service) > should depend on that service, so that applications undeploy if the TSR > is stopped. > > [3] is also related to the the [1] effort and would be impacted by the > above mentioned changes. > > Scott > > [1] EntityManager caching https://issues.jboss.org/browse/WFLY-11233 > > [2] https://paste.fedoraproject.org/paste/-wHaYB3mzR2yTXTfU3LbZA > > [3] Ensure that Hibernate uses direct reference to TSR for better > performance https://issues.jboss.org/browse/WFLY-11243 > _______________________________________________ > 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/20181114/66d02b7d/attachment.html From sam.thomas at broadcom.com Wed Nov 14 21:44:53 2018 From: sam.thomas at broadcom.com (Sam Thomas) Date: Thu, 15 Nov 2018 08:14:53 +0530 Subject: [wildfly-dev] -Xbootclasspath/p:jboss-logmanager-.jar equivalent during runtime In-Reply-To: References: Message-ID: Hi James, Oh I see, that makes total sense - since premain() executes before LogManager is configured. But when agentmain() is executes it?s afterwards. I wouldn?t need to replicate this behavior. I would probably have add a new one if I don?t get one that I need. Am I correct? Thanks ./Sam On Wed, Nov 14, 2018 at 11:38 PM James Perkins wrote: > I'm not sure I follow. The only time the log manager is required to be on > the boot class path is if the agent creates a logger before the > java.util.logging.LogManager is configured. > > On Tue, Nov 13, 2018 at 6:17 PM Sam Thomas > wrote: > >> Hi, >> >> I understand when starting jboss you can supply the above to specify the >> logmanager. If this is not supplied during start up and an agent connects >> to jboss during runtime using agentmain(), how can I replicate the >> -Xbootclasspath/p: behavior during runtime? >> >> Thanks and Regards >> Sam Thomas >> > _______________________________________________ >> 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 > -- Thanks ./Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181115/ccd9cfe3/attachment.html From jperkins at redhat.com Wed Nov 14 22:15:51 2018 From: jperkins at redhat.com (James Perkins) Date: Wed, 14 Nov 2018 19:15:51 -0800 Subject: [wildfly-dev] -Xbootclasspath/p:jboss-logmanager-.jar equivalent during runtime In-Reply-To: References: Message-ID: Hi Sam, It just depends if the any method on the java.util.logging.LogManager gets invoked before JBoss Modules sets the java.util.logging.manager=org.jboss.logmanager.LogManager system property. This happens fairly early in the main entry point of jboss-modules. [1]: https://github.com/jboss-modules/jboss-modules/blob/1.8.6.Final/src/main/java/org/jboss/modules/Main.java#L520-L528 On Wed, Nov 14, 2018 at 6:45 PM Sam Thomas wrote: > Hi James, > > Oh I see, that makes total sense - since premain() executes before > LogManager is configured. But when agentmain() is executes it?s afterwards. > I wouldn?t need to replicate this behavior. I would probably have add a new > one if I don?t get one that I need. Am I correct? > > Thanks > ./Sam > > On Wed, Nov 14, 2018 at 11:38 PM James Perkins > wrote: > >> I'm not sure I follow. The only time the log manager is required to be on >> the boot class path is if the agent creates a logger before the >> java.util.logging.LogManager is configured. >> >> On Tue, Nov 13, 2018 at 6:17 PM Sam Thomas >> wrote: >> >>> Hi, >>> >>> I understand when starting jboss you can supply the above to specify the >>> logmanager. If this is not supplied during start up and an agent connects >>> to jboss during runtime using agentmain(), how can I replicate the >>> -Xbootclasspath/p: behavior during runtime? >>> >>> Thanks and Regards >>> Sam Thomas >>> >> _______________________________________________ >>> 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 >> > -- > > Thanks > ./Sam > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181114/c0e0ea9d/attachment-0001.html From sam.thomas at broadcom.com Wed Nov 14 23:06:22 2018 From: sam.thomas at broadcom.com (Sam Thomas) Date: Thu, 15 Nov 2018 09:36:22 +0530 Subject: [wildfly-dev] -Xbootclasspath/p:jboss-logmanager-.jar equivalent during runtime In-Reply-To: References: Message-ID: Hi James, Hmm I see. One Final question. When an agent starts up with the JVM I have seen this as well -Xbootclasspath/p:jboss-logmanager-.jar;log4j-jboss-logmanager-.jar. So when we don't provide these arguments at startup and the agent attaches later, the log4j manager will not be present. So I would have to alter the LogManager object or something like that. Changing the system property that points to these guys is not going to make it work right? Or am I understanding this wrong and only one of them is used (whichever is found first). Thanks ./Sam On Thu, Nov 15, 2018 at 8:46 AM James Perkins wrote: > Hi Sam, > It just depends if the any method on the java.util.logging.LogManager gets > invoked before JBoss Modules sets the > java.util.logging.manager=org.jboss.logmanager.LogManager system property. > This happens fairly early in the main entry point of jboss-modules. > > [1]: > https://github.com/jboss-modules/jboss-modules/blob/1.8.6.Final/src/main/java/org/jboss/modules/Main.java#L520-L528 > > On Wed, Nov 14, 2018 at 6:45 PM Sam Thomas > wrote: > >> Hi James, >> >> Oh I see, that makes total sense - since premain() executes before >> LogManager is configured. But when agentmain() is executes it?s afterwards. >> I wouldn?t need to replicate this behavior. I would probably have add a new >> one if I don?t get one that I need. Am I correct? >> >> Thanks >> ./Sam >> >> On Wed, Nov 14, 2018 at 11:38 PM James Perkins >> wrote: >> >>> I'm not sure I follow. The only time the log manager is required to be >>> on the boot class path is if the agent creates a logger before the >>> java.util.logging.LogManager is configured. >>> >>> On Tue, Nov 13, 2018 at 6:17 PM Sam Thomas >>> wrote: >>> >>>> Hi, >>>> >>>> I understand when starting jboss you can supply the above to specify >>>> the logmanager. If this is not supplied during start up and an agent >>>> connects to jboss during runtime using agentmain(), how can I replicate the >>>> -Xbootclasspath/p: behavior during runtime? >>>> >>>> Thanks and Regards >>>> Sam Thomas >>>> >>> _______________________________________________ >>>> 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 >>> >> -- >> >> Thanks >> ./Sam >> > > > -- > James R. Perkins > JBoss by Red Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181115/266e87bd/attachment.html From mnovak at redhat.com Thu Nov 15 03:04:53 2018 From: mnovak at redhat.com (Miroslav Novak) Date: Thu, 15 Nov 2018 03:04:53 -0500 (EST) Subject: [wildfly-dev] Wildfly cloud operator In-Reply-To: References: Message-ID: <838319509.33998142.1542269093329.JavaMail.zimbra@redhat.com> Adding messaging pov: Basically the same problem as for transactions needs to be solved for Artemis. Artemis has its own journal where unfinished transactions needs to be recovered in case that Pod with WF crashes. Another issue is scale down. If Pod with WF/Artemis is scale down then operator must move messages to other WF/Artemis cluster nodes. Is wildlfy-operator handling those problems? Thanks, Mirek ----- Original Message ----- > From: "Tom Jenkinson" > To: "Ondra Chaloupka" > Cc: "WildFly Dev" > Sent: Wednesday, 14 November, 2018 5:51:50 PM > Subject: Re: [wildfly-dev] Wildfly cloud operator > > It would also miss the highlighting general lack of EJB remoting and JTS > support for transaction propagation. > > I guess there are other restrictions and guidance for WFLY that might exist. > > On 14 November 2018 at 16:00, Ondra Chaloupka < ochaloup at redhat.com > wrote: > > > > Hi, > > First I have to admit I don't have first hand experience with operators but I > would like to add my point of view here. > > The readme says it's an operator which provides way to startup WildFly server > in k8s clustered with kubeping protocol and creating an ingress resource to > allow inbound connection from outside world[1]. It let you define your > standalone.xml to start with and define deployment to run in the container. > The code talks the same[2]. The creator of the operator is a company[3] > providing cloud based solution so I expect they take what is the best > suiting for the customers - aka. creating a java web application and deploy > it easily to WildFly on k8s. > > As I participate on the WildFly transaction integration for OpenShift[2] I > would like highlight that the operator miss for example the logic for > handling reliable transaction recovery[4]. And other settings that is > offered by cct_modules[5]. > > Ondra > > [1] https://github.com/banzaicloud/wildfly-operator/blob/master/README.md > [2] > https://github.com/banzaicloud/wildfly-operator/blob/master/pkg/stub/handler.go#L37 > [3] https://banzaicloud.com/ > [4] https://issues.jboss.org/browse/CLOUD-2261 > [5] https://github.com/jboss-openshift/cct_module > > On Thu, Nov 8, 2018 at 4:03 PM Ken Wills < kwills at redhat.com > wrote: > > > > Hi Marek, > > On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic < mmarusic at redhat.com > wrote: > > > > Hello Everyone, > > The operator-framework [1] allows to create various operators for cloud. > There is already wildfly-operator [1] created with operator-framework [2]. > Does this operator cover all needed scenarios needed for cloud or are there > any plans to create official Wildfly operator? > > Thanks for linking this, I hadn't seen it. There is a fair amount of other > configuration support that could be provided via operator vs what I see > here, but its a good example. (Basically anything you might want to change > in the configuration, and I'd tend towards using the CLI vs manipulating the > XML directly.) > > Ken > > > > > [1] https://github.com/operator-framework/operator-sdk > [2] https://github.com/banzaicloud/wildfly-operator > > Thank you and wish you a wonderful day, > Marek > > > > Marek Marusic > > Associate Software Engineer - JBOSS SET TEAM > > > Red Hat > > > > Purky?ova 111, 612 00 Brno > > mmarusic at redhat.com > TRIED. TESTED. TRUSTED. > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From ochaloup at redhat.com Thu Nov 15 03:32:19 2018 From: ochaloup at redhat.com (Ondra Chaloupka) Date: Thu, 15 Nov 2018 09:32:19 +0100 Subject: [wildfly-dev] Wildfly cloud operator In-Reply-To: <838319509.33998142.1542269093329.JavaMail.zimbra@redhat.com> References: <838319509.33998142.1542269093329.JavaMail.zimbra@redhat.com> Message-ID: What I can see the wildfly-operator does not handle that either. On Thu, Nov 15, 2018 at 9:05 AM Miroslav Novak wrote: > Adding messaging pov: > Basically the same problem as for transactions needs to be solved for > Artemis. Artemis has its own journal where unfinished transactions needs to > be recovered in case that Pod with WF crashes. Another issue is scale down. > If Pod with WF/Artemis is scale down then operator must move messages to > other WF/Artemis cluster nodes. Is wildlfy-operator handling those problems? > > Thanks, > Mirek > > ----- Original Message ----- > > From: "Tom Jenkinson" > > To: "Ondra Chaloupka" > > Cc: "WildFly Dev" > > Sent: Wednesday, 14 November, 2018 5:51:50 PM > > Subject: Re: [wildfly-dev] Wildfly cloud operator > > > > It would also miss the highlighting general lack of EJB remoting and JTS > > support for transaction propagation. > > > > I guess there are other restrictions and guidance for WFLY that might > exist. > > > > On 14 November 2018 at 16:00, Ondra Chaloupka < ochaloup at redhat.com > > wrote: > > > > > > > > Hi, > > > > First I have to admit I don't have first hand experience with operators > but I > > would like to add my point of view here. > > > > The readme says it's an operator which provides way to startup WildFly > server > > in k8s clustered with kubeping protocol and creating an ingress resource > to > > allow inbound connection from outside world[1]. It let you define your > > standalone.xml to start with and define deployment to run in the > container. > > The code talks the same[2]. The creator of the operator is a company[3] > > providing cloud based solution so I expect they take what is the best > > suiting for the customers - aka. creating a java web application and > deploy > > it easily to WildFly on k8s. > > > > As I participate on the WildFly transaction integration for OpenShift[2] > I > > would like highlight that the operator miss for example the logic for > > handling reliable transaction recovery[4]. And other settings that is > > offered by cct_modules[5]. > > > > Ondra > > > > [1] > https://github.com/banzaicloud/wildfly-operator/blob/master/README.md > > [2] > > > https://github.com/banzaicloud/wildfly-operator/blob/master/pkg/stub/handler.go#L37 > > [3] https://banzaicloud.com/ > > [4] https://issues.jboss.org/browse/CLOUD-2261 > > [5] https://github.com/jboss-openshift/cct_module > > > > On Thu, Nov 8, 2018 at 4:03 PM Ken Wills < kwills at redhat.com > wrote: > > > > > > > > Hi Marek, > > > > On Thu, Nov 8, 2018 at 3:35 AM Marek Marusic < mmarusic at redhat.com > > wrote: > > > > > > > > Hello Everyone, > > > > The operator-framework [1] allows to create various operators for cloud. > > There is already wildfly-operator [1] created with operator-framework > [2]. > > Does this operator cover all needed scenarios needed for cloud or are > there > > any plans to create official Wildfly operator? > > > > Thanks for linking this, I hadn't seen it. There is a fair amount of > other > > configuration support that could be provided via operator vs what I see > > here, but its a good example. (Basically anything you might want to > change > > in the configuration, and I'd tend towards using the CLI vs manipulating > the > > XML directly.) > > > > Ken > > > > > > > > > > [1] https://github.com/operator-framework/operator-sdk > > [2] https://github.com/banzaicloud/wildfly-operator > > > > Thank you and wish you a wonderful day, > > Marek > > > > > > > > Marek Marusic > > > > Associate Software Engineer - JBOSS SET TEAM > > > > > > Red Hat > > > > > > > > Purky?ova 111, 612 00 Brno > > > > mmarusic at redhat.com > > TRIED. TESTED. TRUSTED. > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > _______________________________________________ > > 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/20181115/2e2f0bda/attachment-0001.html From smaestri at redhat.com Thu Nov 15 04:41:42 2018 From: smaestri at redhat.com (Stefano Maestri) Date: Thu, 15 Nov 2018 10:41:42 +0100 Subject: [wildfly-dev] JPA container and IronJacamar Synchronizations are registered using org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry but the Hibernate ORM Synchronizations are registered via org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper In-Reply-To: References: <170ceb59-6b77-19e2-1b95-29364f01ee36@redhat.com> Message-ID: On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson wrote: > The JCAOrderedLastSynchronizationList is intended to guarnatee the > ordering in the JVM so it seems very likely it should be used. > +1 > I wonder why the wrapper is not being injected into JPA and JCA? > I don't see any reason in fact. And I don't remember any issues or discussion specific to this. Best, S. > > On 14 November 2018 at 17:34, Scott Marlow wrote: > >> Hi, >> >> I made a local change to JCAOrderedLastSynchronizationList, to have the >> JPA container (TransactionUtil$SessionSynchronization) afterCompletion() >> always be run after Hibernate afterCompletion() but before the JCA >> afterCompletion(). As I am implementing EntityManager caching [1] and >> want to ensure that the EntityManager instances are only returned to the >> cache after the EntityManager is expected to be available for reuse. >> >> In my debugging, I noticed that the JCAOrderedLastSynchronizationList >> only has the Hibernate synchronizations being added but not the JCA or >> JPA container synchronizations. [2] shows that the JCA + JPA >> Synchronizations are registered via >> org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry >> and Hibernate ORM Synchronization is registered via the >> >> org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper >> >> Should >> org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry >> be changed to use JCAOrderedLastSynchronizationList as well, so that >> IronJacamar (JCA) Synchronizations are run in the correct order? >> >> Should we change the JPA subsystem/container to also ensure that >> Hibernate ORM 5.3 uses the ContextTransactionSynchronizationRegistry >> instead of the >> org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper? >> >> >> >> Is there a WildFly service that represents the >> org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry >> lifecycle? The JPA persistence unit service (or global JPA service) >> should depend on that service, so that applications undeploy if the TSR >> is stopped. >> >> [3] is also related to the the [1] effort and would be impacted by the >> above mentioned changes. >> >> Scott >> >> [1] EntityManager caching https://issues.jboss.org/browse/WFLY-11233 >> >> [2] https://paste.fedoraproject.org/paste/-wHaYB3mzR2yTXTfU3LbZA >> >> [3] Ensure that Hibernate uses direct reference to TSR for better >> performance https://issues.jboss.org/browse/WFLY-11243 >> _______________________________________________ >> 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/20181115/93424de6/attachment.html From tom.jenkinson at redhat.com Thu Nov 15 05:39:50 2018 From: tom.jenkinson at redhat.com (Tom Jenkinson) Date: Thu, 15 Nov 2018 10:39:50 +0000 Subject: [wildfly-dev] JPA container and IronJacamar Synchronizations are registered using org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry but the Hibernate ORM Synchronizations are registered via org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper In-Reply-To: References: <170ceb59-6b77-19e2-1b95-29364f01ee36@redhat.com> Message-ID: On 15 November 2018 at 09:41, Stefano Maestri wrote: > > > On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson > wrote: > >> The JCAOrderedLastSynchronizationList is intended to guarnatee the >> ordering in the JVM so it seems very likely it should be used. >> > > +1 > > > >> I wonder why the wrapper is not being injected into JPA and JCA? >> > > I don't see any reason in fact. And I don't remember any issues or > discussion specific to this. > Hi Scott, I suggest to open a WFLY issue with the details and any reproducer you can provide - thanks! > > Best, > S. > > > > >> >> On 14 November 2018 at 17:34, Scott Marlow wrote: >> >>> Hi, >>> >>> I made a local change to JCAOrderedLastSynchronizationList, to have the >>> JPA container (TransactionUtil$SessionSynchronization) >>> afterCompletion() >>> always be run after Hibernate afterCompletion() but before the JCA >>> afterCompletion(). As I am implementing EntityManager caching [1] and >>> want to ensure that the EntityManager instances are only returned to the >>> cache after the EntityManager is expected to be available for reuse. >>> >>> In my debugging, I noticed that the JCAOrderedLastSynchronizationList >>> only has the Hibernate synchronizations being added but not the JCA or >>> JPA container synchronizations. [2] shows that the JCA + JPA >>> Synchronizations are registered via >>> org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry >>> >>> and Hibernate ORM Synchronization is registered via the >>> org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegi >>> stryWrapper >>> >>> Should >>> org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry >>> >>> be changed to use JCAOrderedLastSynchronizationList as well, so that >>> IronJacamar (JCA) Synchronizations are run in the correct order? >>> >>> Should we change the JPA subsystem/container to also ensure that >>> Hibernate ORM 5.3 uses the ContextTransactionSynchronizationRegistry >>> instead of the >>> org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper? >>> >>> >>> >>> Is there a WildFly service that represents the >>> org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry >>> >>> lifecycle? The JPA persistence unit service (or global JPA service) >>> should depend on that service, so that applications undeploy if the TSR >>> is stopped. >>> >>> [3] is also related to the the [1] effort and would be impacted by the >>> above mentioned changes. >>> >>> Scott >>> >>> [1] EntityManager caching https://issues.jboss.org/browse/WFLY-11233 >>> >>> [2] https://paste.fedoraproject.org/paste/-wHaYB3mzR2yTXTfU3LbZA >>> >>> [3] Ensure that Hibernate uses direct reference to TSR for better >>> performance https://issues.jboss.org/browse/WFLY-11243 >>> _______________________________________________ >>> 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/20181115/e6edbc05/attachment.html From sam.thomas at broadcom.com Thu Nov 15 08:49:48 2018 From: sam.thomas at broadcom.com (Sam Thomas) Date: Thu, 15 Nov 2018 19:19:48 +0530 Subject: [wildfly-dev] -Djboss.modules.system.pkgs=class1, class2 runtime equivalent Message-ID: Hi guys! When an agent starts up with the JVM (through premain()) we can specify in the command to start up jboss, classes to be added to jboss system packages by setting the above property. I am looking to replicate the effect of setting that system property after jboss has started up, i.e, an agent will be loaded through agentmain() after jboss is up and running. All help is appreciated. Thanks and Regards Sam Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181115/9fcd9a26/attachment.html From david.lloyd at redhat.com Thu Nov 15 09:52:22 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 15 Nov 2018 08:52:22 -0600 Subject: [wildfly-dev] -Djboss.modules.system.pkgs=class1, class2 runtime equivalent In-Reply-To: References: Message-ID: On Thu, Nov 15, 2018 at 8:38 AM Sam Thomas wrote: > Hi guys! > > When an agent starts up with the JVM (through premain()) we can specify in the command to start up jboss, classes to be added to jboss system packages by setting the above property. > > I am looking to replicate the effect of setting that system property after jboss has started up, i.e, an agent will be loaded through agentmain() after jboss is up and running. At present, these values are calculated when JBoss Modules starts up and stored in a constant field. So to change that exact mechanism with one which can be reloaded would require that the field be made mutable and that an operation be added which recomputes that field. This is to say that it is possible, but the current code doesn't do that. -- - DML From smarlow at redhat.com Thu Nov 15 11:01:19 2018 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 15 Nov 2018 11:01:19 -0500 Subject: [wildfly-dev] JPA container and IronJacamar Synchronizations are registered using org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry but the Hibernate ORM Synchronizations are registered via org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper In-Reply-To: References: <170ceb59-6b77-19e2-1b95-29364f01ee36@redhat.com> Message-ID: <5670670f-7c4a-a8a8-8281-8802f0b04b78@redhat.com> On 11/15/18 5:39 AM, Tom Jenkinson wrote: > > > On 15 November 2018 at 09:41, Stefano Maestri > wrote: > > > > On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson > > wrote: > > The JCAOrderedLastSynchronizationList is intended to guarnatee > the ordering in the JVM so it seems very likely it should be used. > > > +1 > > I wonder why the wrapper is not being injected into JPA and JCA? > > > I don't see any reason in fact. And I don't remember any issues or > discussion specific to this. > > > Hi Scott, I suggest to open a WFLY issue with the details and any > reproducer you can provide - thanks! https://issues.jboss.org/browse/WFLY-11360 asks the question: " Apparently we are doing a JNDI lookup of "java:jboss/TransactionSynchronizationRegistry" for Hibernate ORM integration, which means we are using the org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper for Hibernate ORM. Should we also be using the org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper class in other WildFly call sites, instead of org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry? " Responses in the jira are welcome :) Scott > > > Best, > S. > > > > On 14 November 2018 at 17:34, Scott Marlow > wrote: > > Hi, > > I made a local change to JCAOrderedLastSynchronizationList, > to have the > JPA container (TransactionUtil$SessionSynchronization) > afterCompletion() > always be run after Hibernate afterCompletion() but before > the JCA > afterCompletion().? As I am implementing EntityManager > caching [1] and > want to ensure that the EntityManager instances are only > returned to the > cache after the EntityManager is expected to be available > for reuse. > > In my debugging, I noticed that the > JCAOrderedLastSynchronizationList > only has the Hibernate synchronizations being added but not > the JCA or > JPA container synchronizations.? [2] shows that the JCA + JPA > Synchronizations are registered via > org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry > > and Hibernate ORM Synchronization is registered via the > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper > > Should > org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry > > be changed to use JCAOrderedLastSynchronizationList as well, > so that > IronJacamar (JCA) Synchronizations are run in the correct order? > > Should we change the JPA subsystem/container to also ensure > that > Hibernate ORM 5.3 uses the > ContextTransactionSynchronizationRegistry > instead of the > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper? > > > > Is there a WildFly service that represents the > org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry > > lifecycle?? The JPA persistence unit service (or global JPA > service) > should depend on that service, so that applications undeploy > if the TSR > is stopped. > > [3] is also related to the the [1] effort and would be > impacted by the > above mentioned changes. > > Scott > > [1] EntityManager caching > https://issues.jboss.org/browse/WFLY-11233 > > > [2] > https://paste.fedoraproject.org/paste/-wHaYB3mzR2yTXTfU3LbZA > > > [3] Ensure that Hibernate uses direct reference to TSR for > better > performance https://issues.jboss.org/browse/WFLY-11243 > > _______________________________________________ > 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 sam.thomas at broadcom.com Thu Nov 15 11:56:57 2018 From: sam.thomas at broadcom.com (Sam Thomas) Date: Thu, 15 Nov 2018 22:26:57 +0530 Subject: [wildfly-dev] -Djboss.modules.system.pkgs=class1, class2 runtime equivalent In-Reply-To: References: Message-ID: Hi David, Can you point me to that field(the class as well) that stores these values? I assume just changing the value(after making the field mutable) to include additional classes isn?t going to be enough? Thanks ./Sam On Thu, Nov 15, 2018 at 8:22 PM David Lloyd wrote: > On Thu, Nov 15, 2018 at 8:38 AM Sam Thomas > wrote: > > Hi guys! > > > > When an agent starts up with the JVM (through premain()) we can specify > in the command to start up jboss, classes to be added to jboss system > packages by setting the above property. > > > > I am looking to replicate the effect of setting that system property > after jboss has started up, i.e, an agent will be loaded through > agentmain() after jboss is up and running. > > At present, these values are calculated when JBoss Modules starts up > and stored in a constant field. So to change that exact mechanism > with one which can be reloaded would require that the field be made > mutable and that an operation be added which recomputes that field. > This is to say that it is possible, but the current code doesn't do > that. > > -- > - DML > -- Thanks ./Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181115/3b692a13/attachment.html From brian.stansberry at redhat.com Thu Nov 15 12:10:48 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 15 Nov 2018 11:10:48 -0600 Subject: [wildfly-dev] JPA container and IronJacamar Synchronizations are registered using org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry but the Hibernate ORM Synchronizations are registered via org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper In-Reply-To: <5670670f-7c4a-a8a8-8281-8802f0b04b78@redhat.com> References: <170ceb59-6b77-19e2-1b95-29364f01ee36@redhat.com> <5670670f-7c4a-a8a8-8281-8802f0b04b78@redhat.com> Message-ID: I suspect this is a bug I introduced in WFLY-11166, which was not meant to change any behavior but perhaps did. I'm having a look. On Thu, Nov 15, 2018 at 10:02 AM Scott Marlow wrote: > > > On 11/15/18 5:39 AM, Tom Jenkinson wrote: > > > > > > On 15 November 2018 at 09:41, Stefano Maestri > > wrote: > > > > > > > > On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson > > > wrote: > > > > The JCAOrderedLastSynchronizationList is intended to guarnatee > > the ordering in the JVM so it seems very likely it should be > used. > > > > > > +1 > > > > I wonder why the wrapper is not being injected into JPA and JCA? > > > > > > I don't see any reason in fact. And I don't remember any issues or > > discussion specific to this. > > > > > > Hi Scott, I suggest to open a WFLY issue with the details and any > > reproducer you can provide - thanks! > > https://issues.jboss.org/browse/WFLY-11360 asks the question: > > " > Apparently we are doing a JNDI lookup of > "java:jboss/TransactionSynchronizationRegistry" for Hibernate ORM > integration, which means we are using the > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper > > for Hibernate ORM. Should we also be using the > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper > > class in other WildFly call sites, instead of > org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry? > " > > Responses in the jira are welcome :) > > Scott > > > > > > > Best, > > S. > > > > > > > > On 14 November 2018 at 17:34, Scott Marlow > > wrote: > > > > Hi, > > > > I made a local change to JCAOrderedLastSynchronizationList, > > to have the > > JPA container (TransactionUtil$SessionSynchronization) > > afterCompletion() > > always be run after Hibernate afterCompletion() but before > > the JCA > > afterCompletion(). As I am implementing EntityManager > > caching [1] and > > want to ensure that the EntityManager instances are only > > returned to the > > cache after the EntityManager is expected to be available > > for reuse. > > > > In my debugging, I noticed that the > > JCAOrderedLastSynchronizationList > > only has the Hibernate synchronizations being added but not > > the JCA or > > JPA container synchronizations. [2] shows that the JCA + JPA > > Synchronizations are registered via > > > org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry > > > > and Hibernate ORM Synchronization is registered via the > > > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper > > > > Should > > > org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry > > > > be changed to use JCAOrderedLastSynchronizationList as well, > > so that > > IronJacamar (JCA) Synchronizations are run in the correct > order? > > > > Should we change the JPA subsystem/container to also ensure > > that > > Hibernate ORM 5.3 uses the > > ContextTransactionSynchronizationRegistry > > instead of the > > > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper? > > > > > > > > Is there a WildFly service that represents the > > > org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry > > > > lifecycle? The JPA persistence unit service (or global JPA > > service) > > should depend on that service, so that applications undeploy > > if the TSR > > is stopped. > > > > [3] is also related to the the [1] effort and would be > > impacted by the > > above mentioned changes. > > > > Scott > > > > [1] EntityManager caching > > https://issues.jboss.org/browse/WFLY-11233 > > > > > > [2] > > https://paste.fedoraproject.org/paste/-wHaYB3mzR2yTXTfU3LbZA > > < > https://paste.fedoraproject.org/paste/-wHaYB3mzR2yTXTfU3LbZA> > > > > [3] Ensure that Hibernate uses direct reference to TSR for > > better > > performance https://issues.jboss.org/browse/WFLY-11243 > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org wildfly-dev at lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > _______________________________________________ > 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 Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181115/7ba80bf1/attachment-0001.html From david.lloyd at redhat.com Thu Nov 15 12:24:38 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 15 Nov 2018 11:24:38 -0600 Subject: [wildfly-dev] -Djboss.modules.system.pkgs=class1, class2 runtime equivalent In-Reply-To: References: Message-ID: Have a look at the static initializer of the org.jboss.modules.Module class. If you extracted the computation of those two fields to a method, and then made the fields volatile, you would be able to re-call the method whenever you've updated the system property. The fields are consulted on each class lookup so changes should take effect immediately. On Thu, Nov 15, 2018 at 10:57 AM Sam Thomas wrote: > > Hi David, > > Can you point me to that field(the class as well) that stores these values? I assume just changing the value(after making the field mutable) to include additional classes isn?t going to be enough? > > Thanks > ./Sam > > On Thu, Nov 15, 2018 at 8:22 PM David Lloyd wrote: >> >> On Thu, Nov 15, 2018 at 8:38 AM Sam Thomas wrote: >> > Hi guys! >> > >> > When an agent starts up with the JVM (through premain()) we can specify in the command to start up jboss, classes to be added to jboss system packages by setting the above property. >> > >> > I am looking to replicate the effect of setting that system property after jboss has started up, i.e, an agent will be loaded through agentmain() after jboss is up and running. >> >> At present, these values are calculated when JBoss Modules starts up >> and stored in a constant field. So to change that exact mechanism >> with one which can be reloaded would require that the field be made >> mutable and that an operation be added which recomputes that field. >> This is to say that it is possible, but the current code doesn't do >> that. >> >> -- >> - DML > > -- > > Thanks > ./Sam -- - DML From brian.stansberry at redhat.com Thu Nov 15 12:33:14 2018 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Thu, 15 Nov 2018 11:33:14 -0600 Subject: [wildfly-dev] JPA container and IronJacamar Synchronizations are registered using org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry but the Hibernate ORM Synchronizations are registered via org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper In-Reply-To: References: <170ceb59-6b77-19e2-1b95-29364f01ee36@redhat.com> <5670670f-7c4a-a8a8-8281-8802f0b04b78@redhat.com> Message-ID: Sorry, ContextTransactionSynchronizationRegistry is not usable in the way WFLY-11166 contemplated. LocalTransactionContextService wires the org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper into the builder object that's meant to drive the org.wildfly.transaction.client stuff but it turns out that object is just discarded, and ContextTransactionSynchronizationRegistry doesn't use it. I'll work up a revert commit. On Thu, Nov 15, 2018 at 11:10 AM Brian Stansberry < brian.stansberry at redhat.com> wrote: > I suspect this is a bug I introduced in WFLY-11166, which was not meant to > change any behavior but perhaps did. I'm having a look. > > On Thu, Nov 15, 2018 at 10:02 AM Scott Marlow wrote: > >> >> >> On 11/15/18 5:39 AM, Tom Jenkinson wrote: >> > >> > >> > On 15 November 2018 at 09:41, Stefano Maestri > > > wrote: >> > >> > >> > >> > On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson >> > > wrote: >> > >> > The JCAOrderedLastSynchronizationList is intended to guarnatee >> > the ordering in the JVM so it seems very likely it should be >> used. >> > >> > >> > +1 >> > >> > I wonder why the wrapper is not being injected into JPA and JCA? >> > >> > >> > I don't see any reason in fact. And I don't remember any issues or >> > discussion specific to this. >> > >> > >> > Hi Scott, I suggest to open a WFLY issue with the details and any >> > reproducer you can provide - thanks! >> >> https://issues.jboss.org/browse/WFLY-11360 asks the question: >> >> " >> Apparently we are doing a JNDI lookup of >> "java:jboss/TransactionSynchronizationRegistry" for Hibernate ORM >> integration, which means we are using the >> org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper >> >> for Hibernate ORM. Should we also be using the >> org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper >> >> class in other WildFly call sites, instead of >> org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry? >> " >> >> Responses in the jira are welcome :) >> >> Scott >> >> > >> > >> > Best, >> > S. >> > >> > >> > >> > On 14 November 2018 at 17:34, Scott Marlow > > > wrote: >> > >> > Hi, >> > >> > I made a local change to JCAOrderedLastSynchronizationList, >> > to have the >> > JPA container (TransactionUtil$SessionSynchronization) >> > afterCompletion() >> > always be run after Hibernate afterCompletion() but before >> > the JCA >> > afterCompletion(). As I am implementing EntityManager >> > caching [1] and >> > want to ensure that the EntityManager instances are only >> > returned to the >> > cache after the EntityManager is expected to be available >> > for reuse. >> > >> > In my debugging, I noticed that the >> > JCAOrderedLastSynchronizationList >> > only has the Hibernate synchronizations being added but not >> > the JCA or >> > JPA container synchronizations. [2] shows that the JCA + >> JPA >> > Synchronizations are registered via >> > >> org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry >> > >> > and Hibernate ORM Synchronization is registered via the >> > >> org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper >> > >> > Should >> > >> org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry >> > >> > be changed to use JCAOrderedLastSynchronizationList as well, >> > so that >> > IronJacamar (JCA) Synchronizations are run in the correct >> order? >> > >> > Should we change the JPA subsystem/container to also ensure >> > that >> > Hibernate ORM 5.3 uses the >> > ContextTransactionSynchronizationRegistry >> > instead of the >> > >> org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper? >> > >> > >> > >> > Is there a WildFly service that represents the >> > >> org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry >> > >> > lifecycle? The JPA persistence unit service (or global JPA >> > service) >> > should depend on that service, so that applications undeploy >> > if the TSR >> > is stopped. >> > >> > [3] is also related to the the [1] effort and would be >> > impacted by the >> > above mentioned changes. >> > >> > Scott >> > >> > [1] EntityManager caching >> > https://issues.jboss.org/browse/WFLY-11233 >> > >> > >> > [2] >> > >> https://paste.fedoraproject.org/paste/-wHaYB3mzR2yTXTfU3LbZA >> > < >> https://paste.fedoraproject.org/paste/-wHaYB3mzR2yTXTfU3LbZA> >> > >> > [3] Ensure that Hibernate uses direct reference to TSR for >> > better >> > performance https://issues.jboss.org/browse/WFLY-11243 >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org > wildfly-dev at lists.jboss.org> >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> > >> > >> > _______________________________________________ >> > wildfly-dev mailing list >> > wildfly-dev at lists.jboss.org > > >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> > >> > >> _______________________________________________ >> 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 > Red Hat > -- Brian Stansberry Manager, Senior Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181115/4ebbad79/attachment.html From sam.thomas at broadcom.com Thu Nov 15 13:09:10 2018 From: sam.thomas at broadcom.com (Sam Thomas) Date: Thu, 15 Nov 2018 23:39:10 +0530 Subject: [wildfly-dev] -Djboss.modules.system.pkgs=class1, class2 runtime equivalent In-Reply-To: References: Message-ID: Cool I will look it up and get back to you if I'm stuck. Thank you for your help David. Thanks ./Sam On Thu, Nov 15, 2018 at 10:55 PM David Lloyd wrote: > Have a look at the static initializer of the org.jboss.modules.Module > class. If you extracted the computation of those two fields to a > method, and then made the fields volatile, you would be able to > re-call the method whenever you've updated the system property. > > The fields are consulted on each class lookup so changes should take > effect immediately. > On Thu, Nov 15, 2018 at 10:57 AM Sam Thomas > wrote: > > > > Hi David, > > > > Can you point me to that field(the class as well) that stores these > values? I assume just changing the value(after making the field mutable) to > include additional classes isn?t going to be enough? > > > > Thanks > > ./Sam > > > > On Thu, Nov 15, 2018 at 8:22 PM David Lloyd > wrote: > >> > >> On Thu, Nov 15, 2018 at 8:38 AM Sam Thomas > wrote: > >> > Hi guys! > >> > > >> > When an agent starts up with the JVM (through premain()) we can > specify in the command to start up jboss, classes to be added to jboss > system packages by setting the above property. > >> > > >> > I am looking to replicate the effect of setting that system property > after jboss has started up, i.e, an agent will be loaded through > agentmain() after jboss is up and running. > >> > >> At present, these values are calculated when JBoss Modules starts up > >> and stored in a constant field. So to change that exact mechanism > >> with one which can be reloaded would require that the field be made > >> mutable and that an operation be added which recomputes that field. > >> This is to say that it is possible, but the current code doesn't do > >> that. > >> > >> -- > >> - DML > > > > -- > > > > Thanks > > ./Sam > > > > -- > - DML > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181115/5cb50759/attachment-0001.html From smarlow at redhat.com Thu Nov 15 13:54:43 2018 From: smarlow at redhat.com (Scott Marlow) Date: Thu, 15 Nov 2018 13:54:43 -0500 Subject: [wildfly-dev] JPA container and IronJacamar Synchronizations are registered using org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry but the Hibernate ORM Synchronizations are registered via org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper In-Reply-To: References: <170ceb59-6b77-19e2-1b95-29364f01ee36@redhat.com> <5670670f-7c4a-a8a8-8281-8802f0b04b78@redhat.com> Message-ID: <7f9e89ce-415a-a614-6e5b-9cae260a4bda@redhat.com> Hi Brian, Thanks, I am late to finding the same (verified that 4fafb7d1387efe924be3ebf2f1b8923ef2be188a worked correctly), just cross linked the jiras :) Scott On 11/15/18 12:33 PM, Brian Stansberry wrote: > Sorry, ContextTransactionSynchronizationRegistry is not usable in the > way WFLY-11166 contemplated.?LocalTransactionContextService wires the > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper > into the builder object that's meant to drive the > org.wildfly.transaction.client stuff but it turns out that object is > just discarded, and ContextTransactionSynchronizationRegistry doesn't > use it. > > I'll work up a revert commit. > > On Thu, Nov 15, 2018 at 11:10 AM Brian Stansberry > > wrote: > > I suspect this is a bug I introduced in WFLY-11166, which was not > meant to change any behavior but perhaps did. I'm having a look. > > On Thu, Nov 15, 2018 at 10:02 AM Scott Marlow > wrote: > > > > On 11/15/18 5:39 AM, Tom Jenkinson wrote: > > > > > > On 15 November 2018 at 09:41, Stefano Maestri > > > >> wrote: > > > > > > > >? ? ?On Wed, Nov 14, 2018 at 10:55 PM Tom Jenkinson > >? ? ? > >> wrote: > > > >? ? ? ? ?The JCAOrderedLastSynchronizationList is intended to > guarnatee > >? ? ? ? ?the ordering in the JVM so it seems very likely it > should be used. > > > > > >? ? ?+1 > > > >? ? ? ? ?I wonder why the wrapper is not being injected into > JPA and JCA? > > > > > >? ? ?I don't see any reason in fact. And I don't remember any > issues or > >? ? ?discussion specific to this. > > > > > > Hi Scott, I suggest to open a WFLY issue with the details and > any > > reproducer you can provide - thanks! > > https://issues.jboss.org/browse/WFLY-11360 asks the question: > > " > Apparently we are doing a JNDI lookup of > "java:jboss/TransactionSynchronizationRegistry" for Hibernate ORM > integration, which means we are using the > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper > > for Hibernate ORM. Should we also be using the > org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper > > class in other WildFly call sites, instead of > org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry? > " > > Responses in the jira are welcome :) > > Scott > > > > > > >? ? ?Best, > >? ? ?S. > > > > > > > >? ? ? ? ?On 14 November 2018 at 17:34, Scott Marlow > > >? ? ? ? ? >> wrote: > > > >? ? ? ? ? ? ?Hi, > > > >? ? ? ? ? ? ?I made a local change to > JCAOrderedLastSynchronizationList, > >? ? ? ? ? ? ?to have the > >? ? ? ? ? ? ?JPA container > (TransactionUtil$SessionSynchronization) > >? ? ? ? ? ? ?afterCompletion() > >? ? ? ? ? ? ?always be run after Hibernate afterCompletion() > but before > >? ? ? ? ? ? ?the JCA > >? ? ? ? ? ? ?afterCompletion().? As I am implementing > EntityManager > >? ? ? ? ? ? ?caching [1] and > >? ? ? ? ? ? ?want to ensure that the EntityManager instances > are only > >? ? ? ? ? ? ?returned to the > >? ? ? ? ? ? ?cache after the EntityManager is expected to be > available > >? ? ? ? ? ? ?for reuse. > > > >? ? ? ? ? ? ?In my debugging, I noticed that the > >? ? ? ? ? ? ?JCAOrderedLastSynchronizationList > >? ? ? ? ? ? ?only has the Hibernate synchronizations being > added but not > >? ? ? ? ? ? ?the JCA or > >? ? ? ? ? ? ?JPA container synchronizations.? [2] shows that > the JCA + JPA > >? ? ? ? ? ? ?Synchronizations are registered via > > > ?org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry > > > >? ? ? ? ? ? ?and Hibernate ORM Synchronization is registered > via the > > > ?org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper > > > >? ? ? ? ? ? ?Should > > > ?org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry > > > >? ? ? ? ? ? ?be changed to use > JCAOrderedLastSynchronizationList as well, > >? ? ? ? ? ? ?so that > >? ? ? ? ? ? ?IronJacamar (JCA) Synchronizations are run in the > correct order? > > > >? ? ? ? ? ? ?Should we change the JPA subsystem/container to > also ensure > >? ? ? ? ? ? ?that > >? ? ? ? ? ? ?Hibernate ORM 5.3 uses the > >? ? ? ? ? ? ?ContextTransactionSynchronizationRegistry > >? ? ? ? ? ? ?instead of the > > > ?org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper? > > > > > > > >? ? ? ? ? ? ?Is there a WildFly service that represents the > > > ?org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry > > > >? ? ? ? ? ? ?lifecycle?? The JPA persistence unit service (or > global JPA > >? ? ? ? ? ? ?service) > >? ? ? ? ? ? ?should depend on that service, so that > applications undeploy > >? ? ? ? ? ? ?if the TSR > >? ? ? ? ? ? ?is stopped. > > > >? ? ? ? ? ? ?[3] is also related to the the [1] effort and > would be > >? ? ? ? ? ? ?impacted by the > >? ? ? ? ? ? ?above mentioned changes. > > > >? ? ? ? ? ? ?Scott > > > >? ? ? ? ? ? ?[1] EntityManager caching > > https://issues.jboss.org/browse/WFLY-11233 > >? ? ? ? ? ? ? > > > >? ? ? ? ? ? ?[2] > > https://paste.fedoraproject.org/paste/-wHaYB3mzR2yTXTfU3LbZA > > > ? > > > >? ? ? ? ? ? ?[3] Ensure that Hibernate uses direct reference > to TSR for > >? ? ? ? ? ? ?better > >? ? ? ? ? ? ?performance > https://issues.jboss.org/browse/WFLY-11243 > >? ? ? ? ? ? ? > >? ? ? ? ? ? ?_______________________________________________ > >? ? ? ? ? ? ?wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > ? > > > > > >? ? ? ? ?_______________________________________________ > >? ? ? ? ?wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > >? ? ? ? ? > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat > > > > -- > Brian Stansberry > Manager, Senior Principal Software Engineer > Red Hat From jperkins at redhat.com Thu Nov 15 14:50:34 2018 From: jperkins at redhat.com (James Perkins) Date: Thu, 15 Nov 2018 11:50:34 -0800 Subject: [wildfly-dev] -Xbootclasspath/p:jboss-logmanager-.jar equivalent during runtime In-Reply-To: References: Message-ID: Hi Sam, To be honest I'm not too familiar with the lifecycle of an agent. If your agent uses log4j, then you'd likely need to add the log4j-jboss-logmanager library as well. If your agent does not use log4j then it should be safe _not_ to add it. On Wed, Nov 14, 2018 at 8:06 PM Sam Thomas wrote: > Hi James, > > Hmm I see. One Final question. When an agent starts up with the JVM I have > seen this as well > > > -Xbootclasspath/p:jboss-logmanager-.jar;log4j-jboss-logmanager-.jar. > > So when we don't provide these arguments at startup and the agent attaches > later, the log4j manager will not be present. So I would have to alter the > LogManager object or something like that. Changing the system property that > points to these guys is not going to make it work right? Or am I > understanding this wrong and only one of them is used (whichever is found > first). > > Thanks > ./Sam > > > On Thu, Nov 15, 2018 at 8:46 AM James Perkins wrote: > >> Hi Sam, >> It just depends if the any method on the java.util.logging.LogManager >> gets invoked before JBoss Modules sets the >> java.util.logging.manager=org.jboss.logmanager.LogManager system property. >> This happens fairly early in the main entry point of jboss-modules. >> >> [1]: >> https://github.com/jboss-modules/jboss-modules/blob/1.8.6.Final/src/main/java/org/jboss/modules/Main.java#L520-L528 >> >> On Wed, Nov 14, 2018 at 6:45 PM Sam Thomas >> wrote: >> >>> Hi James, >>> >>> Oh I see, that makes total sense - since premain() executes before >>> LogManager is configured. But when agentmain() is executes it?s afterwards. >>> I wouldn?t need to replicate this behavior. I would probably have add a new >>> one if I don?t get one that I need. Am I correct? >>> >>> Thanks >>> ./Sam >>> >>> On Wed, Nov 14, 2018 at 11:38 PM James Perkins >>> wrote: >>> >>>> I'm not sure I follow. The only time the log manager is required to be >>>> on the boot class path is if the agent creates a logger before the >>>> java.util.logging.LogManager is configured. >>>> >>>> On Tue, Nov 13, 2018 at 6:17 PM Sam Thomas >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I understand when starting jboss you can supply the above to specify >>>>> the logmanager. If this is not supplied during start up and an agent >>>>> connects to jboss during runtime using agentmain(), how can I replicate the >>>>> -Xbootclasspath/p: behavior during runtime? >>>>> >>>>> Thanks and Regards >>>>> Sam Thomas >>>>> >>>> _______________________________________________ >>>>> 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 >>>> >>> -- >>> >>> Thanks >>> ./Sam >>> >> >> >> -- >> James R. Perkins >> JBoss by Red Hat >> > -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181115/5b30a271/attachment.html From jmesnil at redhat.com Fri Nov 16 11:34:10 2018 From: jmesnil at redhat.com (Jean-Frederic Mesnil) Date: Fri, 16 Nov 2018 17:34:10 +0100 Subject: [wildfly-dev] Subsystems to advertise implicit and optional dependencies to galleon In-Reply-To: References: <683df9a8-3f82-3f9b-dc23-4a4243e16af5@redhat.com> Message-ID: comments inlined > On 09/11/2018 18:32, Brian Stansberry wrote: >> >> The passive optional dependencies would be advertised with >> RuntimeCapability.addAdditionalPassiveOptionalPackages(optional >> dependency package name). >> >> So to summarize: >> >> - RuntimeCapability.addAdditionalRequiredPackages for all required >> implicit modules >> >> - RuntimeCapability.addAdditionalRequiredPackages to associate optional >> dependencies to a feature >> >> - RuntimeCapability.addAdditionalOptionalPackages for all optional >> implicit dependencies that are not passive >> >> - RuntimeCapability.addAdditionalPassiveOptionalPackages for all >> optional dependencies (implicit or not) that are passive >> >> A good question Alexey raised is whether the capability is the right concept for encapsulating this information. The fact you have to create artificial capabilities to provide this information makes me think Alexey is right. >> The alternative is to record this data in the ResourceDefinition, which is the primary source of the data that's used in the feature spec generation. That?s a good idea. This would solve the logging issues where the resource that registers the DUP (i.e. the /subsystem=logging resource) will indicate the packages that are required for it. The question is does storing them in ResourceDefinition is enough for all cases or do we have to able to keep them attached to a RuntimeCapability. >> I don't think ResourceDefinition has this problem. > I have introduced artificial capabilities in ee, jaxrs and weld (subsystems that are targeted by the demo) to add additional packages. It seems that it would be common case. So it is actually smelly. We should also ensure that we do not introduce artificial resource definition to provide these packages information but that is unlikely. (That reminds me how we used to create artificial subresources to store complex configuration that was only used by the parent resource). >> Is it something that subsystems owner would be ready to put in place to >> help galleon in this task? It would require a bit of analysis of the >> dependencies of your modules but the gain could be quite important. If we want to get buy in from the subsystem developer, we need: * tools to analyzee the dependencies (you already wrote them) * good documentation to explain to a subsystem developer what a optional/required/passive/implicit package means (maybe linking to Galleon from the Javadoc is enough but I am not sure?) Good stuff, Jean-Francois :) Thanks, jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From Andrew.Marlow at fisglobal.com Tue Nov 27 08:02:41 2018 From: Andrew.Marlow at fisglobal.com (Marlow, Andrew) Date: Tue, 27 Nov 2018 13:02:41 +0000 Subject: [wildfly-dev] wildfly14 JMS security config question Message-ID: Hello everyone, I am trying to disable JMS security in wildfly14 with activemq but can't see how to do it. Googling, I find the advice: add " to your config but whereabouts should it be added? I tried immediately after but this gave WFLYCTL0085: Failed to parse configuration. BTW the problem I am trying to solve is user null does not have permission='consume' on address. This is despite me having in my config. Andrew Marlow Consultant developer, Apex 38th Floor, 25 Canada Square, Canary Wharf, London E14 5LQ T: 020-8081-2367 / 07966-451-521 E: andrew.marlow at fisglobal.com FIS | Empowering the Financial World [cid:image001.png at 01D112FA.C4A77D90] [cid:image002.png at 01D112FA.C4A77D90] [cid:image003.png at 01D112FA.C4A77D90] FIS Apex (UK) Limited * Registered in England and Wales No. 3573008 * Registered Office: 38th floor, 25 Canada Square, London, E14 5LQ, United Kingdom [50_3] The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181127/da0e1f60/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 807 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181127/da0e1f60/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 818 bytes Desc: image002.png Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181127/da0e1f60/attachment-0005.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 796 bytes Desc: image003.png Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181127/da0e1f60/attachment-0006.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 19020 bytes Desc: image004.png Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181127/da0e1f60/attachment-0007.png From jdenise at redhat.com Tue Nov 27 09:46:02 2018 From: jdenise at redhat.com (Jean-Francois Denise) Date: Tue, 27 Nov 2018 15:46:02 +0100 Subject: [wildfly-dev] WildFly Elytron - Credential Store - Next Stages In-Reply-To: References: Message-ID: <4cdc9cbf-4eb9-c14a-da3b-6eb8b2a20d7d@redhat.com> Hi Darran, looking at "Automation of Updates to the Store" in which CLI could be involved, I am listing potential issues if the CLI handles it: - it seems that the clear=>store+alias could be on a per operation basis. User could still want to not rely on credential store. So enabling globally the transformation would not work. - Having an interactive workflow would not work well for scripts. - Introducing new headers dedicated to automatic conversion could work (they would have to be recognized and support implemented on server), although with multiple credential-references located in the same command, the syntax could become complex. After having played a bit with CLI+credential-references, I am thinking that defining a new attribute in the credential-reference (existing clear-text and store are alternatives, can't use both) to express that the user wants automatic storage would seem quite natural from CLI. Furthermore, it would work with CLI existing support for operations. Something like {clear-text=mypassword, update-store=mystore, alias=ALIAS} I would enforce that the update-store already exists. If that is possible in elytron subsystem, that would make for a simple CLI workflow. JF On 26/09/2018 15:15, Darran Lofthouse wrote: > During WildFly 15 and WildFly 16 I am looking at the next stages for > credential store development based on a few feature requests we have > not handled yet. > > We are at the stage where this development is likely to affect > multiple areas of the application server, additionally we need to > consider these requests as a set so we don't take a decision for one > that prevents us working on the remainder. > > I have put together a blog post describing some of the general issues > we want to look into: - > > http://darranl.blogspot.com/2018/09/wildfly-elytron-credential-store-next.html > > Some of these changes will have an impact on any subsystem currently > referencing the credential store. > > Other changes we will need to decide if the solution lies within > WildFly Elytron, the management tier of the server, or the admin tools > - or possibly a combination of all three. > > I am also going to share this link in the community forums to try and > obtain some additional feedback from end users. > > Regards, > Darran Lofthouse. > > > _______________________________________________ > 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/20181127/26450abb/attachment.html From darran.lofthouse at jboss.com Tue Nov 27 11:55:09 2018 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 27 Nov 2018 16:55:09 +0000 Subject: [wildfly-dev] WildFly Elytron - Credential Store - Next Stages In-Reply-To: <4cdc9cbf-4eb9-c14a-da3b-6eb8b2a20d7d@redhat.com> References: <4cdc9cbf-4eb9-c14a-da3b-6eb8b2a20d7d@redhat.com> Message-ID: On Tue, Nov 27, 2018 at 2:46 PM Jean-Francois Denise wrote: > Hi Darran, > > looking at "Automation of Updates to the Store" in which CLI could be > involved, I am listing potential issues if the CLI handles it: > > - it seems that the clear=>store+alias could be on a per operation basis. > User could still want to not rely on credential store. So enabling globally > the transformation would not work. > I suspect it would be more a case of if they specify all three attributes we would automatically take the clear password and store it in the referenced credential store using the specified alias. Trying to automatically select a credential store and generate an alias seems more trouble than it would be worth, > - Having an interactive workflow would not work well for scripts. > > - Introducing new headers dedicated to automatic conversion could work > (they would have to be recognized and support implemented on server), > although with multiple credential-references located in the same command, > the syntax could become complex. > > After having played a bit with CLI+credential-references, I am thinking > that defining a new attribute in the credential-reference (existing > clear-text and store are alternatives, can't use both) to express that the > user wants automatic storage would seem quite natural from CLI. > Furthermore, it would work with CLI existing support for operations. > > Something like {clear-text=mypassword, update-store=mystore, alias=ALIAS} > I would enforce that the update-store already exists. > > If that is possible in elytron subsystem, that would make for a simple CLI > workflow. > > JF > On 26/09/2018 15:15, Darran Lofthouse wrote: > > During WildFly 15 and WildFly 16 I am looking at the next stages for > credential store development based on a few feature requests we have not > handled yet. > > We are at the stage where this development is likely to affect multiple > areas of the application server, additionally we need to consider these > requests as a set so we don't take a decision for one that prevents us > working on the remainder. > > I have put together a blog post describing some of the general issues we > want to look into: - > > > http://darranl.blogspot.com/2018/09/wildfly-elytron-credential-store-next.html > > Some of these changes will have an impact on any subsystem currently > referencing the credential store. > > Other changes we will need to decide if the solution lies within WildFly > Elytron, the management tier of the server, or the admin tools - or > possibly a combination of all three. > > I am also going to share this link in the community forums to try and > obtain some additional feedback from end users. > > Regards, > Darran Lofthouse. > > > _______________________________________________ > wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://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/20181127/e543ef35/attachment.html From nikola.malenic at netsetglobal.rs Tue Nov 27 12:41:23 2018 From: nikola.malenic at netsetglobal.rs (Nikola Malenic) Date: Tue, 27 Nov 2018 18:41:23 +0100 Subject: [wildfly-dev] Global module with ejbs Message-ID: <003201d48678$6a13b160$3e3b1420$@netsetglobal.rs> I deployed a global module with remote ejbs defined, but I can't access them from deployed applications. Here is the interface: @Remote public interface ICryptoAPI.. and bean definition: @Stateless public class CryptoAPI implements ICryptoAPI ... How can I find jndi name of the ejbs deployed, since default @Ejb cannot find bean? Just to mention, /subsystem=naming:jndi-view() from jboss-cli doesn't print anything about deployed module and there are no errors in wildfly log. Maybe, it is not possible to define injectable ejbs in global modules? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181127/d4c8d5c9/attachment-0001.html From david.lloyd at redhat.com Tue Nov 27 16:46:29 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 27 Nov 2018 15:46:29 -0600 Subject: [wildfly-dev] Global module with ejbs In-Reply-To: <003201d48678$6a13b160$3e3b1420$@netsetglobal.rs> References: <003201d48678$6a13b160$3e3b1420$@netsetglobal.rs> Message-ID: Correct, EJBs are not discovered from modules. They must be deployed. On Tue, Nov 27, 2018 at 12:07 PM Nikola Malenic wrote: > > I deployed a global module with remote ejbs defined, but I can't access them from deployed applications. > > > > Here is the interface: > > @Remote > > public interface ICryptoAPI.. > > > > and bean definition: > > @Stateless > > public class CryptoAPI implements ICryptoAPI ... > > > > How can I find jndi name of the ejbs deployed, since default @Ejb cannot find bean? Just to mention, /subsystem=naming:jndi-view() from jboss-cli doesn't print anything about deployed module and there are no errors in wildfly log. > > > > Maybe, it is not possible to define injectable ejbs in global modules? > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- - DML From nikola.malenic at netsetglobal.rs Wed Nov 28 04:14:42 2018 From: nikola.malenic at netsetglobal.rs (Nikola Malenic) Date: Wed, 28 Nov 2018 10:14:42 +0100 Subject: [wildfly-dev] Global module with ejbs In-Reply-To: References: <003201d48678$6a13b160$3e3b1420$@netsetglobal.rs> Message-ID: <004001d486fa$cc3f8d50$64bea7f0$@netsetglobal.rs> But how does the injection work with other stuff from modules, e.g. EntityManager? -----Original Message----- From: David Lloyd [mailto:david.lloyd at redhat.com] Sent: Tuesday, November 27, 2018 10:46 PM To: nikola.malenic at netsetglobal.rs Cc: WildFly Dev Subject: Re: [wildfly-dev] Global module with ejbs Correct, EJBs are not discovered from modules. They must be deployed. On Tue, Nov 27, 2018 at 12:07 PM Nikola Malenic wrote: > > I deployed a global module with remote ejbs defined, but I can't access them from deployed applications. > > > > Here is the interface: > > @Remote > > public interface ICryptoAPI.. > > > > and bean definition: > > @Stateless > > public class CryptoAPI implements ICryptoAPI ... > > > > How can I find jndi name of the ejbs deployed, since default @Ejb cannot find bean? Just to mention, /subsystem=naming:jndi-view() from jboss-cli doesn't print anything about deployed module and there are no errors in wildfly log. > > > > Maybe, it is not possible to define injectable ejbs in global modules? > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- - DML From manovotn at redhat.com Wed Nov 28 07:31:37 2018 From: manovotn at redhat.com (Matej Novotny) Date: Wed, 28 Nov 2018 07:31:37 -0500 (EST) Subject: [wildfly-dev] Opentracing extension in WFLY - EAR + Weld Probe In-Reply-To: <1966470105.36982933.1543407329406.JavaMail.zimbra@redhat.com> Message-ID: <1139300829.36985575.1543408297245.JavaMail.zimbra@redhat.com> Hello, during recent Weld release a noticed that one of Weld examples stopped working on WFLY 14. It is an EAR (WAR + EJB JAR) that has no special stuff in it and the error shows a CNFE from open tracing[1] upon deployment. After some digging I realized that we also have Weld Probe (devel tool) on which basically intercepts every bean out there to give you some stats about deployment. That means it will try to create an interceptor from TracerProducer[2] as well and will fail because: 1) the module (opentracing module) has no dependencies on Weld hence cannot load proxies and will delegate this to EAR root ClassLoader[3] - if the module's module.xml has weld-core, this won't fail (but we don't want to dependend on core, that's nasty) 2) EAR root CL doesn't know about opentracing API, hence the CNFE - adding some dependencies there would solve it, we do that for WARs already Looking at opentracing extension, why are there no dependencies added to the root of EAR[4]? For the record I did try removing that 'if' statement and then executing test[5] related to the PR in which it was added and it passed (and solved my deployment problem as well). If the above approach is fine, I can create JIRA and send a PR, I just wanted to check with someone who has more knowledge about that opentracing extension than I do. Regards Matej _______________________________________________________________________________________________________________________ [1] https://issues.jboss.org/browse/WELD-2549 [2] https://github.com/wildfly/wildfly/blob/master/microprofile/opentracing-smallrye/src/main/java/org/wildfly/microprofile/opentracing/smallrye/TracerProducer.java [3] https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/main/java/org/jboss/as/weld/services/bootstrap/ProxyServicesImpl.java#L83 [4] https://github.com/wildfly/wildfly/blob/master/microprofile/opentracing-extension/src/main/java/org/wildfly/extension/microprofile/opentracing/TracingDependencyProcessor.java#L57-L59 [5] https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/microprofile/opentracing/EarOpenTracingTestCase.java From smarlow at redhat.com Wed Nov 28 10:53:11 2018 From: smarlow at redhat.com (Scott Marlow) Date: Wed, 28 Nov 2018 10:53:11 -0500 Subject: [wildfly-dev] Global module with ejbs In-Reply-To: <004001d486fa$cc3f8d50$64bea7f0$@netsetglobal.rs> References: <003201d48678$6a13b160$3e3b1420$@netsetglobal.rs> <004001d486fa$cc3f8d50$64bea7f0$@netsetglobal.rs> Message-ID: On 11/28/18 4:14 AM, Nikola Malenic wrote: > But how does the injection work with other stuff from modules, e.g. EntityManager? > The EntityManager injection [1] is also not handled for global modules, since global modules do not get processed as deployments. If you want to include JPA code in your global module, you could use the javax.persistence.Persistence API [2] to create the EntityManagerFactory from which you can get the EntityManager. Scott [1] https://github.com/wildfly/wildfly/blob/master/jpa/subsystem/src/main/java/org/jboss/as/jpa/processor/JPAAnnotationProcessor.java#L80 [2] https://javaee.github.io/javaee-spec/javadocs/javax/persistence/Persistence.html#createEntityManagerFactory-java.lang.String-java.util.Map- > -----Original Message----- > From: David Lloyd [mailto:david.lloyd at redhat.com] > Sent: Tuesday, November 27, 2018 10:46 PM > To: nikola.malenic at netsetglobal.rs > Cc: WildFly Dev > Subject: Re: [wildfly-dev] Global module with ejbs > > Correct, EJBs are not discovered from modules. They must be deployed. > On Tue, Nov 27, 2018 at 12:07 PM Nikola Malenic wrote: >> >> I deployed a global module with remote ejbs defined, but I can't access them from deployed applications. >> >> >> >> Here is the interface: >> >> @Remote >> >> public interface ICryptoAPI.. >> >> >> >> and bean definition: >> >> @Stateless >> >> public class CryptoAPI implements ICryptoAPI ... >> >> >> >> How can I find jndi name of the ejbs deployed, since default @Ejb cannot find bean? Just to mention, /subsystem=naming:jndi-view() from jboss-cli doesn't print anything about deployed module and there are no errors in wildfly log. >> >> >> >> Maybe, it is not possible to define injectable ejbs in global modules? >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > - DML > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From tom.jenkinson at redhat.com Wed Nov 28 13:08:28 2018 From: tom.jenkinson at redhat.com (Tom Jenkinson) Date: Wed, 28 Nov 2018 18:08:28 +0000 Subject: [wildfly-dev] wildfly14 JMS security config question In-Reply-To: References: Message-ID: Hi Andrew, I suggest to ask this on the WildFly user forum: https://developer.jboss.org/en/wildfly You could tag people like Jeff Mesnil, Clebert Succonic, Martyn Taylor or Andrew Taylor as it seems related to work in their area. Hope that helps, Tom On Tue, 27 Nov 2018 at 13:10, Marlow, Andrew wrote: > Hello everyone, > > > > I am trying to disable JMS security in wildfly14 with activemq but can?t > see how to do it. Googling, I find the advice: add ? enabled=?false?/> to your config but whereabouts should it be added? I > tried immediately after xmlns="urn:jboss:domain:messaging-activemq:4.0"> but this gave WFLYCTL0085: > Failed to parse configuration. > > > > BTW the problem I am trying to solve is user null does not have > permission='consume' on address. This is despite me having > > > > > > > > create-non-durable-queue="true" delete-non-durable-queue="true"/> > > > > > > in my config. > > > > *Andrew Marlow* > > Consultant developer, Apex > > 38th Floor, 25 Canada Square, > > Canary Wharf, London E14 5LQ > > *T*: 020-8081-2367 / 07966-451-521 > *E*: andrew.marlow at fisglobal.com > *FIS | Empowering the Financial World* [image: > cid:image001.png at 01D112FA.C4A77D90] [image: > cid:image002.png at 01D112FA.C4A77D90] [image: > cid:image003.png at 01D112FA.C4A77D90] > > FIS Apex (UK) Limited * Registered in England and Wales No. 3573008 * > Registered Office: 38th floor, 25 Canada Square, London, E14 5LQ, United > Kingdom > > [image: 50_3] > > > The information contained in this message is proprietary and/or > confidential. If you are not the intended recipient, please: (i) delete the > message and all copies; (ii) do not disclose, distribute or use the message > in any manner; and (iii) notify the sender immediately. In addition, please > be aware that any message addressed to our domain is subject to archiving > and review by persons other than the intended recipient. Thank you. > _______________________________________________ > 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/20181128/6b555996/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 807 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181128/6b555996/attachment-0005.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 818 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181128/6b555996/attachment-0006.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 796 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181128/6b555996/attachment-0007.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 19020 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181128/6b555996/attachment-0008.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 796 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181128/6b555996/attachment-0009.png From manovotn at redhat.com Thu Nov 29 08:14:45 2018 From: manovotn at redhat.com (Matej Novotny) Date: Thu, 29 Nov 2018 08:14:45 -0500 (EST) Subject: [wildfly-dev] Opentracing extension in WFLY - EAR + Weld Probe In-Reply-To: References: <1139300829.36985575.1543408297245.JavaMail.zimbra@redhat.com> Message-ID: <506995281.37431520.1543497285314.JavaMail.zimbra@redhat.com> Thanks for your response. I'll send a PR soon as I can get to it. Matej ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: "Matej Novotny" , "WildFly Dev" > Cc: "Martin Kouba" , "Nikoleta Ziakova" > Sent: Thursday, November 29, 2018 1:52:03 PM > Subject: Re: Opentracing extension in WFLY - EAR + Weld Probe > > On 11/28/18 1:31 PM, Matej Novotny wrote: > > during recent Weld release a noticed that one of Weld examples stopped > > working on WFLY 14. > > WF14 shipped with a bug that prevented the subsystem from working properly: > https://issues.jboss.org/browse/WFLY-10961 > > I don't think it affects your examples, though. > > > Looking at opentracing extension, why are there no dependencies added to > > the root of EAR[4]? > > For the record I did try removing that 'if' statement and then executing > > test[5] related to the PR in which it was added and it passed (and solved > > my deployment problem as well). > > If the above approach is fine, I can create JIRA and send a PR, I just > > wanted to check with someone who has more knowledge about that opentracing > > extension than I do. > > I trust your judgment on how it should look like. As long as the tests > are passing, I'd say that it's OK to change. > > IIRC, we needed this conditional statement because we need each > subdeployment to have its own tracer instance. If you are saying that we > can get this scenario without that conditional, please do change it :) > > - Juca. > From kkhan at redhat.com Fri Nov 30 04:40:40 2018 From: kkhan at redhat.com (Kabir Khan) Date: Fri, 30 Nov 2018 09:40:40 +0000 Subject: [wildfly-dev] WildFly 15 frozen Message-ID: Hi all, The WildFly master branch is now frozen until we release WildFly 15.0.0.Final. We need to sync up with Jason, but I expect it to be released today or over the weekend. Thanks, Kabir -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181130/37f4cec2/attachment.html From rory.odonnell at oracle.com Fri Nov 30 06:41:46 2018 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 30 Nov 2018 11:41:46 +0000 Subject: [wildfly-dev] JDK 12 build 22 is now available at : - jdk.java.net/12/ Message-ID: Hi David & Richard,* * *NOTE:- *The JDK 12 schedule rampdown phase 1 of the release is coming up in a few weeks on Dec. 13, 2018. ** *JDK 12 Early Access build 22 **is now available **at : - jdk.java.net/12/* * Release Note updates since last email * * o Build 21 - Deprecating the default keytool -keyalg value (JDK-8212003) o Build 21 - Change to X25519 and X448 encoded private key format (JDK-8213363) o Build 20 - New command-line flag for more extensive error reporting in crash logs? (JDK-8211845) o Build 20 -Initial Value of user.timezone System Property Changed (JDK-8185496) * JEPs proposed for JDK 12 : o JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector(Experimental) o JEP 334: JVM Constants API o JEP 344: Abortable Mixed Collections for G1 o JEP 346: Promptly Return Unused Committed Memory from G1 * JEPs targeted to JDK 12, so far o JEP 230: Microbenchmark Suite o JEP 325: Switch Expressions (Preview) o JEP 326: Raw String Literals (Preview) o JEP 340: One AArch64 Port, Not Two o JEP 341: Default CDS Archives Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181130/70732e4b/attachment.html From jdenise at redhat.com Fri Nov 30 12:44:58 2018 From: jdenise at redhat.com (Jean-Francois Denise) Date: Fri, 30 Nov 2018 18:44:58 +0100 Subject: [wildfly-dev] Wildfly layers Message-ID: Hi, here is an attempt to describe the galleon layers we could see exposed in order to build custom configurations. The way layers are provisioned by galleon make the provisioned server to be much smaller (in term of XML config and num of provisioned modules) than the default installation/configurations. We are here covering standalone kind of configuration. Feedbacks would be really welcome. I took the approach to not have layers to depend on legacy security-realms, we want elytron to be the way to go, so depending on these first place would create a maintainability issue. This does create some complexity when defining default configs, default config have to associate realms with management and subsystems to produce the default standalone configs we know. This complexity is not exposed. Each layer is "runnable", you can provision it and run it. Only common.* and standalone.* scripts are provisioned. Doesn't mean that running it alone makes sense. Any combination of layers should be valid. A layer brings its own dependencies and its XML configuration. Each subsystem (even server) is in charge to advertise to galleon what are the additional modules it is injecting or loading that should be provisioned but are not referenced from extension module. All the subsystems involved in the following layers have been updated to express these dependencies. Because Full layers are far from being defined, we could expect some adjustment. For core: Layers not bound to subsystems - base-server: root resource, pubic interface and socket binding. All layers depend at least on it. - management: unsecured management interface, management sockets, http-interface - secure-management: depends on management, configures elytron sasl authentication factory for management http interface - tools: all modules and tools script files (cli, add-user,...) - patching: patching modules. Layers bound to subsystems - core-management - deployment-scanner - discovery - elytron (brings openssl artifacts, openssl can't be used if elytron openssl provider is not configured.). - io - jmx - jmx-remoting: depends on jmx and configure remoting-connector. Depend on management (requires jboss.remoting.endpoint.management service) - logging - remoting: depends on io - request-controller - security-manager Aggregation Layer This layer defines a server with elytron secured management and all layers one would expect when running a core-server - core-server: depends on secure-management (brings elytron), jmx-remoting (brings jmx), logging, core-management, request-controller, security-manager. For servlet Layers not bound to subsystems - picketbox: A layer to brings picketbox module (and optional deps of picketbox present in servlet FP). Picketbox could be combined with some core layers without requiring the legacy security subsystem to be present. Layers bound to subsystems - ee: depends on naming - legacy-security (security sub-system): depends on naming and picketbox. - naming - undertow: depends on io and picketbox (to bring optional deps of picketbox, we still have hard dep on picketbox from security-negociation). This is a base undertow server, no security, no https-listener, empty servlet container (no support for servlet, jsp deployments). NB: welcome-content is not part of the layer, it is bring by the default configs. legacy default-security-domain "other" is also not configured, that is done in the default config too. - undertow-load-balancer: depends on io and picketbox. Undertow configured to act as a load-balancer. Web server layer This layer defines a server containing all layers one would expect when running an unsecure web-server. legacy-security is not included. In addition, this layer evolves undertow to be a full servlet-container (jsp, servlet, web-socket) and http-invoker. - web-server: ee (brings naming), deployment-scanner, undertow (brings picketbox and io) A note on combining layers. In order to evolve a web-server to become fully manageable, one would combine core-server (the management features) with web-server (web support). Because core layers are accessible from servlet FP, one could pick and choose from servlet FP to assemble his server. For example, a basic manageable unsecured (but ready to be configured for security) undertow server: undertow+management+elytron For full: We have identified an initial set of layers that would be the building blocks to help define cloud oriented configurations. Layers bound to subsystem: These layers depend (at least) on web-server (from servlet) - cdi: brings in weld and bean-validation - jaxrs - jpa: brings in hibernate default providers. In addition brings-in transactions, jca and infinispan (hibernate infinispan-cache). - activemq-jms: naked subsystem, no server configured. In addition brings-in transactions and jca - microprofile: opentracing, config, healths and metrics (last 2 depend on management). Layers that are simple extension of existing layers (would not appear as new layers but would extend content of servlet/core ones). - ee: add optional dependencies injected by dup present in full FP. - undertow: add undertow.js package. - tools: vault, jdr, wstools, appclient Aggregation layer - cloud-profile: contains cdi,jaxrs,jpa,activemq-jms,microprofile . All optionally included, allowing for exclusion (eg: exclude activemq-jms). Open questions SSL undertow As you noticed we don't have a layer for an SSL undertow. elytron doesn't offer an out of the box generation of self-signed certificate. Only legacy security realms offer this. So the way to go would be to provision undertow+elytron+management+tools (management+tools to use CLI), create the keystore, do the elytron configuration, add an https-listener, set the ssl-context, remove all the management related stuff from CLI. Then exclude the management+tools layers to get a smaller foot-print (tools bring a lot). NB: we could imagine that the CLI configuration is done from a provisioned server that contains tools so no need to provision tools with undertow. I am wandering if we should create an elytron SSL context that points to a "REPLACE_WITH_THE_PATH_TO_YOUR_KEYSTORE" kind of configuration to simplify configuration steps? I don't really like this idea to generate config that points to invalid artifacts but would simplify the configuration steps. Picketbox layer Because we want at some point to get rid-off this dependency, I am wandering if we should really define a layer for it. Could be that any dependency on it would imply the use of legacy-security layer. Picketbox is implicit when legacy-security layer is provisioned. Full layers granularity For now, we have included some major features (transactions, jca, infinispan) without making them layers. The layers that are depending on them are for the only consumers. When we progress with new layers, this would be revisited. Thank-you for having reached the end. ;-) JF From darran.lofthouse at redhat.com Fri Nov 30 13:06:12 2018 From: darran.lofthouse at redhat.com (Darran Lofthouse) Date: Fri, 30 Nov 2018 18:06:12 +0000 Subject: [wildfly-dev] Wildfly layers In-Reply-To: References: Message-ID: FYI out of the box SSL with WildFly Elytron is one of the high priority on our roadmap, after the 10th December we should be able to discuss this one a little further with you. Regards, Darran Lofthouse. On Fri, Nov 30, 2018 at 5:53 PM Jean-Francois Denise wrote: > Hi, > > here is an attempt to describe the galleon layers we could see exposed > in order to build custom configurations. The way layers are provisioned > by galleon make the provisioned server to be much smaller (in term of > XML config and num of provisioned modules) than the default > installation/configurations. We are here covering standalone kind of > configuration. > > Feedbacks would be really welcome. > > I took the approach to not have layers to depend on legacy > security-realms, we want elytron to be the way to go, so depending on > these first place would create a maintainability issue. This does create > some complexity when defining default configs, default config have to > associate realms with management and subsystems to produce the default > standalone configs we know. This complexity is not exposed. > > Each layer is "runnable", you can provision it and run it. Only common.* > and standalone.* scripts are provisioned. Doesn't mean that running it > alone makes sense. > > Any combination of layers should be valid. > > A layer brings its own dependencies and its XML configuration. Each > subsystem (even server) is in charge to advertise to galleon what are > the additional modules it is injecting or loading that should be > provisioned but are not referenced from extension module. All the > subsystems involved in the following layers have been updated to express > these dependencies. > > Because Full layers are far from being defined, we could expect some > adjustment. > > For core: > > Layers not bound to subsystems > > - base-server: root resource, pubic interface and socket binding. All > layers depend at least on it. > - management: unsecured management interface, management sockets, > http-interface > - secure-management: depends on management, configures elytron sasl > authentication factory for management http interface > - tools: all modules and tools script files (cli, add-user,...) > - patching: patching modules. > > Layers bound to subsystems > > - core-management > - deployment-scanner > - discovery > - elytron (brings openssl artifacts, openssl can't be used if elytron > openssl provider is not configured.). > - io > - jmx > - jmx-remoting: depends on jmx and configure remoting-connector. Depend > on management (requires jboss.remoting.endpoint.management service) > - logging > - remoting: depends on io > - request-controller > - security-manager > > Aggregation Layer > > This layer defines a server with elytron secured management and all > layers one would expect when running a core-server > > - core-server: depends on secure-management (brings elytron), > jmx-remoting (brings jmx), logging, core-management, request-controller, > security-manager. > > For servlet > > Layers not bound to subsystems > > - picketbox: A layer to brings picketbox module (and optional deps of > picketbox present in servlet FP). Picketbox could be combined with some > core layers without requiring the legacy security subsystem to be present. > > Layers bound to subsystems > > - ee: depends on naming > - legacy-security (security sub-system): depends on naming and picketbox. > - naming > - undertow: depends on io and picketbox (to bring optional deps of > picketbox, we still have hard dep on picketbox from > security-negociation). This is a base undertow server, no security, no > https-listener, empty servlet container (no support for servlet, jsp > deployments). NB: welcome-content is not part of the layer, it is bring > by the default configs. legacy default-security-domain "other" is also > not configured, that is done in the default config too. > - undertow-load-balancer: depends on io and picketbox. Undertow > configured to act as a load-balancer. > > Web server layer > > This layer defines a server containing all layers one would expect when > running an unsecure web-server. legacy-security is not included. In > addition, this layer evolves undertow to be a full servlet-container > (jsp, servlet, web-socket) and http-invoker. > > - web-server: ee (brings naming), deployment-scanner, undertow (brings > picketbox and io) > > A note on combining layers. > > In order to evolve a web-server to become fully manageable, one would > combine core-server (the management features) with web-server (web > support). > > Because core layers are accessible from servlet FP, one could pick and > choose from servlet FP to assemble his server. For example, a basic > manageable unsecured (but ready to be configured for security) undertow > server: undertow+management+elytron > > > For full: > > We have identified an initial set of layers that would be the building > blocks to help define cloud oriented configurations. > > Layers bound to subsystem: > > These layers depend (at least) on web-server (from servlet) > > - cdi: brings in weld and bean-validation > - jaxrs > - jpa: brings in hibernate default providers. In addition brings-in > transactions, jca and infinispan (hibernate infinispan-cache). > - activemq-jms: naked subsystem, no server configured. In addition > brings-in transactions and jca > - microprofile: opentracing, config, healths and metrics (last 2 depend > on management). > > Layers that are simple extension of existing layers (would not appear as > new layers but would extend content of servlet/core ones). > > - ee: add optional dependencies injected by dup present in full FP. > - undertow: add undertow.js package. > - tools: vault, jdr, wstools, appclient > > Aggregation layer > > - cloud-profile: contains cdi,jaxrs,jpa,activemq-jms,microprofile . All > optionally included, allowing for exclusion (eg: exclude activemq-jms). > > > Open questions > > SSL undertow > > As you noticed we don't have a layer for an SSL undertow. elytron > doesn't offer an out of the box generation of self-signed certificate. > Only legacy security realms offer this. So the way to go would be to > provision undertow+elytron+management+tools (management+tools to use > CLI), create the keystore, do the elytron configuration, add an > https-listener, set the ssl-context, remove all the management related > stuff from CLI. Then exclude the management+tools layers to get a > smaller foot-print (tools bring a lot). NB: we could imagine that the > CLI configuration is done from a provisioned server that contains tools > so no need to provision tools with undertow. > > I am wandering if we should create an elytron SSL context that points to > a "REPLACE_WITH_THE_PATH_TO_YOUR_KEYSTORE" kind of configuration to > simplify configuration steps? I don't really like this idea to generate > config that points to invalid artifacts but would simplify the > configuration steps. > > Picketbox layer > > Because we want at some point to get rid-off this dependency, I am > wandering if we should really define a layer for it. Could be that any > dependency on it would imply the use of legacy-security layer. Picketbox > is implicit when legacy-security layer is provisioned. > > Full layers granularity > > For now, we have included some major features (transactions, jca, > infinispan) without making them layers. The layers that are depending on > them are for the only consumers. When we progress with new layers, this > would be revisited. > > Thank-you for having reached the end. ;-) > > JF > > _______________________________________________ > 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/20181130/c3db606d/attachment-0001.html