From stuart.w.douglas at gmail.com Wed Jul 1 02:12:47 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 01 Jul 2015 06:12:47 +0000 Subject: [wildfly-dev] WFLY-4200 WAR MDB cannot obtain superclass on module classpath In-Reply-To: References: Message-ID: I think the solution here is to just move this to a later phase, where it can be changed to use reflection. Stuart On Wed, 1 Jul 2015 at 02:52 Eduardo Sant?Ana da Silva < eduardo.santanadasilva at gmail.com> wrote: > Hello, I'm planning to do something regarding WFLY-4200, I've sent an > e-mail a few months ago about that and I will need some clarifications. > > I don't know if I'm right, but I'm seeing a big problem with that if this > is really a bug. What other checks are being done that cause the deployment > abort in the other phases before resolving the dependencies that could be > turn the deployment in a qualified one? > > https://issues.jboss.org/browse/WFLY-4200 > > Regards, > Eduardo Sant'Ana da Silva > > 2015-05-02 19:23 GMT-03:00 Eduardo Sant?Ana da Silva < > eduardo.santanadasilva at gmail.com>: > >> I was looking at :WFLY-4200 WAR MDB cannot obtain superclass on module >> classpath >> >> This is what I posted about it: >> >> >> "I believe that the problem is because >> AnnotatedEJBComponentDescriptionDeploymentUnitProcessor executes in the >> parse phase: >> >> Phase.PARSE,Phase.PARSE_CREATE_COMPONENT_DESCRIPTIONS >> >> Since the dependencies will be resolved at Phase.DEPENDENCIES, your >> build will not work. >> Regarding WFLY, my suggestion is not throw the >> EjbLogger.ROOT_LOGGER.mdbDoesNotImplementNorSpecifyMessageListener(beanClass) >> only bring up some flag that the required interfaces were not yet resolved, >> some attachment could be useful, just to retain the super class name. When >> the dependencies were solved, the class will be present on the class index >> and the test against the annotation should be performed again. Since that >> work will be done twice, to verify the required interfaces, this requires >> some experts advice." >> >> Thanks, >> -- >> __________________________ >> Eduardo Sant'Ana da Silva >> >> > > > -- > > _______________________________________________ > 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/20150701/b2ddfb61/attachment.html From eduardo.santanadasilva at gmail.com Wed Jul 1 07:53:35 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Wed, 1 Jul 2015 08:53:35 -0300 Subject: [wildfly-dev] WFLY-4200 WAR MDB cannot obtain superclass on module classpath In-Reply-To: References: Message-ID: Yes it will work fine. I think that WFLY-2939 will be resolved with this approach as well. 2015-07-01 3:12 GMT-03:00 Stuart Douglas : > I think the solution here is to just move this to a later phase, where it > can be changed to use reflection. > > Stuart > > On Wed, 1 Jul 2015 at 02:52 Eduardo Sant?Ana da Silva < > eduardo.santanadasilva at gmail.com> wrote: > >> Hello, I'm planning to do something regarding WFLY-4200, I've sent an >> e-mail a few months ago about that and I will need some clarifications. >> >> I don't know if I'm right, but I'm seeing a big problem with that if this >> is really a bug. What other checks are being done that cause the deployment >> abort in the other phases before resolving the dependencies that could be >> turn the deployment in a qualified one? >> >> https://issues.jboss.org/browse/WFLY-4200 >> >> Regards, >> Eduardo Sant'Ana da Silva >> >> 2015-05-02 19:23 GMT-03:00 Eduardo Sant?Ana da Silva < >> eduardo.santanadasilva at gmail.com>: >> >>> I was looking at :WFLY-4200 WAR MDB cannot obtain superclass on module >>> classpath >>> >>> This is what I posted about it: >>> >>> >>> "I believe that the problem is because >>> AnnotatedEJBComponentDescriptionDeploymentUnitProcessor executes in the >>> parse phase: >>> >>> Phase.PARSE,Phase.PARSE_CREATE_COMPONENT_DESCRIPTIONS >>> >>> Since the dependencies will be resolved at Phase.DEPENDENCIES, your >>> build will not work. >>> Regarding WFLY, my suggestion is not throw the >>> EjbLogger.ROOT_LOGGER.mdbDoesNotImplementNorSpecifyMessageListener(beanClass) >>> only bring up some flag that the required interfaces were not yet resolved, >>> some attachment could be useful, just to retain the super class name. When >>> the dependencies were solved, the class will be present on the class index >>> and the test against the annotation should be performed again. Since that >>> work will be done twice, to verify the required interfaces, this requires >>> some experts advice." >>> >>> Thanks, >>> -- >>> __________________________ >>> Eduardo Sant'Ana da Silva >>> >>> >> >> >> -- >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150701/fd8e957f/attachment-0001.html From tomaz.cerar at gmail.com Wed Jul 1 08:21:32 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 1 Jul 2015 14:21:32 +0200 Subject: [wildfly-dev] Wildfly 9 BOM changes In-Reply-To: <55916C8C.5060508@redhat.com> References: <55916C8C.5060508@redhat.com> Message-ID: Hey Thomas, yes, boms ware modifed to have scope provided, as given the feedback on forums lots of folks had problems with bundling the API jars with their application, which resulted in lots of deployment problems. The testing on other hand results in problems you have, which are quite easily fixed if you change the scope of dependency when you are defining deps for your test modules. Question is what is more common problem, one or another. It is hard to choose what to cater to in this case. I think that best thing do here is to update our quickstarts that reflect how to work with newer boms. Maybe someone else has better idea? -- tomaz On Mon, Jun 29, 2015 at 6:04 PM, Thomas Segismont wrote: > Hi everyone, > > While working on upgrading Hawkular to Wildfly 9 CR2, we have noticed > that the Wildfly BOM now declares provided scope for some dependencies. > > I guess the goal is to help users which forget to set the provided scope > in their POM to end up with all the libraries in their WAR. > > On the other hand, if you use some libraries in your tests, then > dependency resolution can be broken. For example, if you add > org.jboss.resteasy::resteasy-client in test scope, your tests fail due > to a missing class from commons-io, because commons-io should be > resolved as a transitive dependency of > org.jboss.resteasy::resteasy-jaxrs, but it's now in scope provided, > instead of test. > > Have you considered this use case? Are there other motivations than > helping Maven beginners? > > Best regards, > Thomas > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150701/a8263d99/attachment.html From tomaz.cerar at gmail.com Wed Jul 1 08:25:08 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 1 Jul 2015 14:25:08 +0200 Subject: [wildfly-dev] Capabilit integration from services and DeploymentUnitProcessors In-Reply-To: <5592E034.1080505@redhat.com> References: <5592E034.1080505@redhat.com> Message-ID: On Tue, Jun 30, 2015 at 8:30 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > 2) A capability cannot provide services of > 1 value type. It's nice if > capabilities can represent something that's meaningful to an end user, > and there's no reason why something that's meaningful to an end user > might not expose more than one service to other capabilities. If we > limit capabilities to exposing a single service, then we may end up with > multiple capabilities. See [2] for an example case, where a proposed > "org.wildfly.iiop" (nice and simple for an end user to understand) > installs two services, an ORB and a NamingContextExt. > In cases like this capability should still be one service that would than depend on two or more services. and consumer of capability would just get the "aggregator" capability that would than allow access to other two services (or properties on service) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150701/cef60772/attachment.html From smaestri at redhat.com Wed Jul 1 08:25:50 2015 From: smaestri at redhat.com (Stefano Maestri) Date: Wed, 01 Jul 2015 14:25:50 +0200 Subject: [wildfly-dev] WFLYCTL0218: A node is already registered at '/deployment=*/subsystem=datasources/xa-data-source=*/statistics=jdbc' In-Reply-To: <558CE76F.5000601@osnanet.de> References: <558CE76F.5000601@osnanet.de> Message-ID: <5593DC4E.8060400@redhat.com> Can you give me configuration/step to reproduce the bug? I can't reproduce it locally. I've probably found the possible cause, but I'd like to verify it reproducing bug best regards S. On 06/26/2015 07:47 AM, Frank Langelage wrote: > I have a Deja-Vu, I'm very I saw this some months ago. Not it reappears. > > Possibly due to the commit #7605 with changes for "WFLY-4429 Refactor > JCA subsystem". > > 26.06. 00:25:37,390 INFO > [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer#deployXADataSource] > IJ020018: Enabling for > java:jboss/datasources/maj2e-langfr-dev > 26.06. 00:25:37,445 INFO > [org.jboss.as.connector.subsystems.datasources#transition] WFLYJCA0001: > Bound data source [java:jboss/datasources/DefaultDS] > 26.06. 00:25:37,501 INFO > [org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue] > IJ020018: Enabling for > java:/eis/maj2e-langfr-dev/ControllerConnector > 26.06. 00:25:37,509 INFO > [org.jboss.as.connector.deployment#bindConnectionFactory] WFLYJCA0007: > Registered connection factory java:/eis/maj2e-langfr-dev/ControllerConnector > 26.06. 00:25:37,514 INFO > [org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue] > IJ020002: Deployed: > file:/mbi/tools/jboss/10.0/standalone/tmp/vfs/temp/temp91b455ac091637f0/content-9d63fac1b393fd1c/contents/ > 26.06. 00:25:37,801 INFO > [org.jboss.as.connector.subsystems.datasources#transition] WFLYJCA0001: > Bound data source [java:jboss/datasources/maj2e-langfr-dev] > 26.06. 00:25:37,990 ERROR [org.jboss.msc.service.fail#startFailed] > MSC000001: Failed to start service > jboss.data-source.java:jboss/datasources/maj2e-langfr-dev.statistics: > org.jboss.msc.service.StartException in service > jboss.data-source.java:jboss/datasources/maj2e-langfr-dev.statistics: > Failed to start service > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalArgumentException: WFLYCTL0218: A node is > already registered at > '/deployment=*/subsystem=datasources/xa-data-source=*/statistics=jdbc' > at > org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:147) > at > org.jboss.as.connector.services.datasources.statistics.DataSourceStatisticsService.start(DataSourceStatisticsService.java:83) > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From mazz at redhat.com Wed Jul 1 09:06:02 2015 From: mazz at redhat.com (John Mazzitelli) Date: Wed, 1 Jul 2015 09:06:02 -0400 (EDT) Subject: [wildfly-dev] Wildfly 9 BOM changes In-Reply-To: References: <55916C8C.5060508@redhat.com> Message-ID: <388256458.11157806.1435755962760.JavaMail.zimbra@redhat.com> I was under the impression the best-practice "Maven-way" is to never specify scope in BOMs (dependencyManagement) - let the importers of the BOM determine the scope of the dependencies (to avoid the problems Thomas is reporting). IMO, we should stick with the standard Maven best-practice and not provide a scope. Anyone, therefore, importing BOMs should (usually) know they have to worry about providing their scope since that's the normal operating procedure in Maven BOM usage. This SO entry talks about this and the one response indicates problems with transitive deps if you put scope in dependencyManagement (which sounds like the same reason why WildFly has it - to specify "the most common" scope): http://stackoverflow.com/questions/15221299/dependencymanagement-and-scope I'm sure there are other reasons why not to do this. IMO, we should avoid the hassles this is going to introduce - keep scope out of the BOM. ----- Original Message ----- > Hey Thomas, > > yes, boms ware modifed to have scope provided, as given the feedback on > forums lots of folks had problems with > bundling the API jars with their application, which resulted in lots of > deployment problems. > > The testing on other hand results in problems you have, which are quite > easily fixed if you change the scope of dependency > when you are defining deps for your test modules. > > Question is what is more common problem, one or another. It is hard to choose > what to cater to in this case. > > I think that best thing do here is to update our quickstarts that reflect how > to work with newer boms. > > > Maybe someone else has better idea? > > -- > tomaz > > > > On Mon, Jun 29, 2015 at 6:04 PM, Thomas Segismont < tsegismo at redhat.com > > wrote: > > > Hi everyone, > > While working on upgrading Hawkular to Wildfly 9 CR2, we have noticed > that the Wildfly BOM now declares provided scope for some dependencies. > > I guess the goal is to help users which forget to set the provided scope > in their POM to end up with all the libraries in their WAR. > > On the other hand, if you use some libraries in your tests, then > dependency resolution can be broken. For example, if you add > org.jboss.resteasy::resteasy-client in test scope, your tests fail due > to a missing class from commons-io, because commons-io should be > resolved as a transitive dependency of > org.jboss.resteasy::resteasy-jaxrs, but it's now in scope provided, > instead of test. > > Have you considered this use case? Are there other motivations than > helping Maven beginners? > > Best regards, > Thomas > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Wed Jul 1 11:03:56 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 01 Jul 2015 10:03:56 -0500 Subject: [wildfly-dev] Capabilit integration from services and DeploymentUnitProcessors In-Reply-To: References: <5592E034.1080505@redhat.com> Message-ID: <5594015C.6010905@redhat.com> On 7/1/15 7:25 AM, Toma? Cerar wrote: > > On Tue, Jun 30, 2015 at 8:30 PM, Brian Stansberry > > wrote: > > 2) A capability cannot provide services of > 1 value type. It's nice if > capabilities can represent something that's meaningful to an end user, > and there's no reason why something that's meaningful to an end user > might not expose more than one service to other capabilities. If we > limit capabilities to exposing a single service, then we may end up with > multiple capabilities. See [2] for an example case, where a proposed > "org.wildfly.iiop" (nice and simple for an end user to understand) > installs two services, an ORB and a NamingContextExt. > > > > In cases like this capability should still be one service that would > than depend on two or more services. > and consumer of capability would just get the "aggregator" capability > that would than allow access > to other two services (or properties on service) Aha! Very good point. If a capability exposes a custom runtime integration API (i.e. not a service), there can only be one and then consumers would just invoke whatever methods were relevant to them. This is analogous. I'm happy then with 1 service per capability and a single fixed pattern for creating the service names. OT: I suspect there will be little need for custom runtime APIs, as in many cases a service could provide whatever it does. Thanks, Brian From tomaz.cerar at gmail.com Wed Jul 1 12:26:45 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 1 Jul 2015 18:26:45 +0200 Subject: [wildfly-dev] Capabilit integration from services and DeploymentUnitProcessors In-Reply-To: <5594015C.6010905@redhat.com> References: <5592E034.1080505@redhat.com> <5594015C.6010905@redhat.com> Message-ID: On Wed, Jul 1, 2015 at 5:03 PM, Brian Stansberry < brian.stansberry at redhat.com> wrote: > OT: I suspect there will be little need for custom runtime APIs, as in > many cases a service could provide whatever it does. There are few cases where this is / will be needed, it is similar to what we have found with web-common when we ware doing web --> undertow co-existence. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150701/fcb983c6/attachment.html From brian.stansberry at redhat.com Wed Jul 1 12:43:25 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 01 Jul 2015 11:43:25 -0500 Subject: [wildfly-dev] Discarding the changed management model during operation rollback Message-ID: <559418AD.1070402@redhat.com> tl;dr; When an operation that has changed the management model is rolling back, the OperationStepHandlers processing the rollback see the model as it was at the arbitrary point when the rollback began. I propose changing this so they see things as they were prior to the first change to the model. Long version: When an operation mutates either the management Resource tree, or the registry of capabilities (together known as the management model), we clone the management model and thereafter that operation works on the clone. The clone is invisible to other callers until the operations successfully commits. When the operation commits, it publishes the clone and that becomes the official model. I call this copy-on-write, publish-on-commit. If the operation rolls back, the changed model is never published and the clone is just discarded when the operation execution returns. However, while the operation is rolling back, all the OperationStepHandlers that are processing the rollback see the modified clone, not the original model. They are seeing arbitrarily incorrect data. This hasn't been a problem up to now, as our standard OSHs get a copy of whatever part of the Resource tree they are going to modify and keep it for use in rollback. They don't need to re-read the management model to perform rollback. But this doesn't work for the capability registry. If an OSH removes a capability and removes a service, and then in rollback tries to use the capability to figure out how to restore the service, it fails, as management model it can see still shows the capability as being removed. To fix this, I propose discarding the cloned management model as soon as rollback begins. Thereafter, an OSH processing rollback will see the model as it was before the first modification. The removed capability will still be present. I have a commit that does this at [1]. Running the testsuite with it shows no regressions. This doesn't surprise me, as our standard OSHs up to now have had no need to re-read the model during rollback. [1] https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9aa514de08c01bf976be -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jperkins at redhat.com Wed Jul 1 13:01:39 2015 From: jperkins at redhat.com (James R. Perkins) Date: Wed, 1 Jul 2015 10:01:39 -0700 Subject: [wildfly-dev] Discarding the changed management model during operation rollback In-Reply-To: <559418AD.1070402@redhat.com> References: <559418AD.1070402@redhat.com> Message-ID: <55941CF3.3040403@redhat.com> Not much more I can say than +1. I can't think of a good reason why an OSH would need to know anything about the failed model update on a rollback. On 07/01/2015 09:43 AM, Brian Stansberry wrote: > tl;dr; > > When an operation that has changed the management model is rolling back, > the OperationStepHandlers processing the rollback see the model as it > was at the arbitrary point when the rollback began. I propose changing > this so they see things as they were prior to the first change to the model. > > Long version: > > When an operation mutates either the management Resource tree, or the > registry of capabilities (together known as the management model), we > clone the management model and thereafter that operation works on the > clone. The clone is invisible to other callers until the operations > successfully commits. When the operation commits, it publishes the clone > and that becomes the official model. > > I call this copy-on-write, publish-on-commit. > > If the operation rolls back, the changed model is never published and > the clone is just discarded when the operation execution returns. > > However, while the operation is rolling back, all the > OperationStepHandlers that are processing the rollback see the modified > clone, not the original model. They are seeing arbitrarily incorrect data. > > This hasn't been a problem up to now, as our standard OSHs get a copy of > whatever part of the Resource tree they are going to modify and keep it > for use in rollback. They don't need to re-read the management model to > perform rollback. > > But this doesn't work for the capability registry. If an OSH removes a > capability and removes a service, and then in rollback tries to use the > capability to figure out how to restore the service, it fails, as > management model it can see still shows the capability as being removed. > > To fix this, I propose discarding the cloned management model as soon as > rollback begins. Thereafter, an OSH processing rollback will see the > model as it was before the first modification. The removed capability > will still be present. > > I have a commit that does this at [1]. Running the testsuite with it > shows no regressions. This doesn't surprise me, as our standard OSHs up > to now have had no need to re-read the model during rollback. > > [1] > https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9aa514de08c01bf976be > -- James R. Perkins JBoss by Red Hat From jason.greene at redhat.com Wed Jul 1 14:03:03 2015 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 1 Jul 2015 13:03:03 -0500 Subject: [wildfly-dev] Discarding the changed management model during operation rollback In-Reply-To: <559418AD.1070402@redhat.com> References: <559418AD.1070402@redhat.com> Message-ID: I completely agree. > On Jul 1, 2015, at 11:43 AM, Brian Stansberry wrote: > > tl;dr; > > When an operation that has changed the management model is rolling back, > the OperationStepHandlers processing the rollback see the model as it > was at the arbitrary point when the rollback began. I propose changing > this so they see things as they were prior to the first change to the model. > > Long version: > > When an operation mutates either the management Resource tree, or the > registry of capabilities (together known as the management model), we > clone the management model and thereafter that operation works on the > clone. The clone is invisible to other callers until the operations > successfully commits. When the operation commits, it publishes the clone > and that becomes the official model. > > I call this copy-on-write, publish-on-commit. > > If the operation rolls back, the changed model is never published and > the clone is just discarded when the operation execution returns. > > However, while the operation is rolling back, all the > OperationStepHandlers that are processing the rollback see the modified > clone, not the original model. They are seeing arbitrarily incorrect data. > > This hasn't been a problem up to now, as our standard OSHs get a copy of > whatever part of the Resource tree they are going to modify and keep it > for use in rollback. They don't need to re-read the management model to > perform rollback. > > But this doesn't work for the capability registry. If an OSH removes a > capability and removes a service, and then in rollback tries to use the > capability to figure out how to restore the service, it fails, as > management model it can see still shows the capability as being removed. > > To fix this, I propose discarding the cloned management model as soon as > rollback begins. Thereafter, an OSH processing rollback will see the > model as it was before the first modification. The removed capability > will still be present. > > I have a commit that does this at [1]. Running the testsuite with it > shows no regressions. This doesn't surprise me, as our standard OSHs up > to now have had no need to re-read the model during rollback. > > [1] > https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9aa514de08c01bf976be > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From eduardo.santanadasilva at gmail.com Wed Jul 1 18:33:49 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Wed, 1 Jul 2015 19:33:49 -0300 Subject: [wildfly-dev] WFLY-4200 WAR MDB cannot obtain superclass on module classpath In-Reply-To: References: Message-ID: Stuart, I think that the target change will be on: class : MessageDrivenComponentDescriptionFactory method: getMessageListenerInterface that is used by processMessageBeans as well. MessageDrivenComponentDescriptionFactory, is called on AnnotatedEJBComponentDescriptionDeploymentUnitProcessor class, public AnnotatedEJBComponentDescriptionDeploymentUnitProcessor(final boolean appclient) { super(appclient); this.appclient = appclient; this.factories = new EJBComponentDescriptionFactory[] { new MessageDrivenComponentDescriptionFactory(appclient), new SessionBeanComponentDescriptionFactory(appclient) }; } It will be enough to change the phase when AnnotatedEJBComponentDescriptionDeploymentUnitProcessor is executed on EJB3SubsystemAdd, and do the due change on code using reflection? Or will this impact other things regarding message driven beans that should be done on PARSE phase? processorTarget.addDeploymentProcessor(EJB3Extension. SUBSYSTEM_NAME, Phase.PARSE, Phase.PARSE_CREATE_COMPONENT_DESCRIPTIONS, new AnnotatedEJBComponentDescriptionDeploymentUnitProcessor(appclient)); And what will be the exact phase to do the AnnotatedEJBComponentDescriptionDeploymentUnitProcessor? Do you have some code that I could use as reference? Thanks, Eduardo Sant'Ana da Silva 2015-07-01 3:12 GMT-03:00 Stuart Douglas : > I think the solution here is to just move this to a later phase, where it > can be changed to use reflection. > > Stuart > > On Wed, 1 Jul 2015 at 02:52 Eduardo Sant?Ana da Silva < > eduardo.santanadasilva at gmail.com> wrote: > >> Hello, I'm planning to do something regarding WFLY-4200, I've sent an >> e-mail a few months ago about that and I will need some clarifications. >> >> I don't know if I'm right, but I'm seeing a big problem with that if this >> is really a bug. What other checks are being done that cause the deployment >> abort in the other phases before resolving the dependencies that could be >> turn the deployment in a qualified one? >> >> https://issues.jboss.org/browse/WFLY-4200 >> >> Regards, >> Eduardo Sant'Ana da Silva >> >> 2015-05-02 19:23 GMT-03:00 Eduardo Sant?Ana da Silva < >> eduardo.santanadasilva at gmail.com>: >> >>> I was looking at :WFLY-4200 WAR MDB cannot obtain superclass on module >>> classpath >>> >>> This is what I posted about it: >>> >>> >>> "I believe that the problem is because >>> AnnotatedEJBComponentDescriptionDeploymentUnitProcessor executes in the >>> parse phase: >>> >>> Phase.PARSE,Phase.PARSE_CREATE_COMPONENT_DESCRIPTIONS >>> >>> Since the dependencies will be resolved at Phase.DEPENDENCIES, your >>> build will not work. >>> Regarding WFLY, my suggestion is not throw the >>> EjbLogger.ROOT_LOGGER.mdbDoesNotImplementNorSpecifyMessageListener(beanClass) >>> only bring up some flag that the required interfaces were not yet resolved, >>> some attachment could be useful, just to retain the super class name. When >>> the dependencies were solved, the class will be present on the class index >>> and the test against the annotation should be performed again. Since that >>> work will be done twice, to verify the required interfaces, this requires >>> some experts advice." >>> >>> Thanks, >>> -- >>> __________________________ >>> Eduardo Sant'Ana da Silva >>> >>> >> >> >> -- >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150701/ed83427c/attachment.html From kabir.khan at jboss.com Thu Jul 2 03:49:02 2015 From: kabir.khan at jboss.com (Kabir Khan) Date: Thu, 2 Jul 2015 09:49:02 +0200 Subject: [wildfly-dev] Discarding the changed management model during operation rollback In-Reply-To: References: <559418AD.1070402@redhat.com> Message-ID: <44B93087-8435-4571-A111-9F03CE4FC821@jboss.com> Me too > On 1 Jul 2015, at 20:03, Jason Greene wrote: > > I completely agree. > >> On Jul 1, 2015, at 11:43 AM, Brian Stansberry wrote: >> >> tl;dr; >> >> When an operation that has changed the management model is rolling back, >> the OperationStepHandlers processing the rollback see the model as it >> was at the arbitrary point when the rollback began. I propose changing >> this so they see things as they were prior to the first change to the model. >> >> Long version: >> >> When an operation mutates either the management Resource tree, or the >> registry of capabilities (together known as the management model), we >> clone the management model and thereafter that operation works on the >> clone. The clone is invisible to other callers until the operations >> successfully commits. When the operation commits, it publishes the clone >> and that becomes the official model. >> >> I call this copy-on-write, publish-on-commit. >> >> If the operation rolls back, the changed model is never published and >> the clone is just discarded when the operation execution returns. >> >> However, while the operation is rolling back, all the >> OperationStepHandlers that are processing the rollback see the modified >> clone, not the original model. They are seeing arbitrarily incorrect data. >> >> This hasn't been a problem up to now, as our standard OSHs get a copy of >> whatever part of the Resource tree they are going to modify and keep it >> for use in rollback. They don't need to re-read the management model to >> perform rollback. >> >> But this doesn't work for the capability registry. If an OSH removes a >> capability and removes a service, and then in rollback tries to use the >> capability to figure out how to restore the service, it fails, as >> management model it can see still shows the capability as being removed. >> >> To fix this, I propose discarding the cloned management model as soon as >> rollback begins. Thereafter, an OSH processing rollback will see the >> model as it was before the first modification. The removed capability >> will still be present. >> >> I have a commit that does this at [1]. Running the testsuite with it >> shows no regressions. This doesn't surprise me, as our standard OSHs up >> to now have had no need to re-read the model during rollback. >> >> [1] >> https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9aa514de08c01bf976be >> >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From tomaz.cerar at gmail.com Thu Jul 2 05:33:43 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 2 Jul 2015 11:33:43 +0200 Subject: [wildfly-dev] Discarding the changed management model during operation rollback In-Reply-To: <44B93087-8435-4571-A111-9F03CE4FC821@jboss.com> References: <559418AD.1070402@redhat.com> <44B93087-8435-4571-A111-9F03CE4FC821@jboss.com> Message-ID: So if we are doing +1s, then +1 :) On Thu, Jul 2, 2015 at 9:49 AM, Kabir Khan wrote: > Me too > > On 1 Jul 2015, at 20:03, Jason Greene wrote: > > > > I completely agree. > > > >> On Jul 1, 2015, at 11:43 AM, Brian Stansberry < > brian.stansberry at redhat.com> wrote: > >> > >> tl;dr; > >> > >> When an operation that has changed the management model is rolling back, > >> the OperationStepHandlers processing the rollback see the model as it > >> was at the arbitrary point when the rollback began. I propose changing > >> this so they see things as they were prior to the first change to the > model. > >> > >> Long version: > >> > >> When an operation mutates either the management Resource tree, or the > >> registry of capabilities (together known as the management model), we > >> clone the management model and thereafter that operation works on the > >> clone. The clone is invisible to other callers until the operations > >> successfully commits. When the operation commits, it publishes the clone > >> and that becomes the official model. > >> > >> I call this copy-on-write, publish-on-commit. > >> > >> If the operation rolls back, the changed model is never published and > >> the clone is just discarded when the operation execution returns. > >> > >> However, while the operation is rolling back, all the > >> OperationStepHandlers that are processing the rollback see the modified > >> clone, not the original model. They are seeing arbitrarily incorrect > data. > >> > >> This hasn't been a problem up to now, as our standard OSHs get a copy of > >> whatever part of the Resource tree they are going to modify and keep it > >> for use in rollback. They don't need to re-read the management model to > >> perform rollback. > >> > >> But this doesn't work for the capability registry. If an OSH removes a > >> capability and removes a service, and then in rollback tries to use the > >> capability to figure out how to restore the service, it fails, as > >> management model it can see still shows the capability as being removed. > >> > >> To fix this, I propose discarding the cloned management model as soon as > >> rollback begins. Thereafter, an OSH processing rollback will see the > >> model as it was before the first modification. The removed capability > >> will still be present. > >> > >> I have a commit that does this at [1]. Running the testsuite with it > >> shows no regressions. This doesn't surprise me, as our standard OSHs up > >> to now have had no need to re-read the model during rollback. > >> > >> [1] > >> > https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9aa514de08c01bf976be > >> > >> -- > >> Brian Stansberry > >> Senior Principal Software Engineer > >> JBoss by Red Hat > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > > Jason T. Greene > > WildFly Lead / JBoss EAP Platform Architect > > JBoss, a division of Red Hat > > > > > > _______________________________________________ > > 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/20150702/54784cb1/attachment-0001.html From hbraun at redhat.com Thu Jul 2 06:12:50 2015 From: hbraun at redhat.com (Heiko Braun) Date: Thu, 2 Jul 2015 12:12:50 +0200 Subject: [wildfly-dev] Discarding the changed management model during operation rollback In-Reply-To: References: <559418AD.1070402@redhat.com> <44B93087-8435-4571-A111-9F03CE4FC821@jboss.com> Message-ID: <64008387-8818-4524-8310-391B2150A6F7@redhat.com> Yeah feels like we are apache.org +1 > Am 02.07.2015 um 11:33 schrieb Toma? Cerar : > > So if we are doing +1s, then > +1 > > :) > >> On Thu, Jul 2, 2015 at 9:49 AM, Kabir Khan wrote: >> Me too >> > On 1 Jul 2015, at 20:03, Jason Greene wrote: >> > >> > I completely agree. >> > >> >> On Jul 1, 2015, at 11:43 AM, Brian Stansberry wrote: >> >> >> >> tl;dr; >> >> >> >> When an operation that has changed the management model is rolling back, >> >> the OperationStepHandlers processing the rollback see the model as it >> >> was at the arbitrary point when the rollback began. I propose changing >> >> this so they see things as they were prior to the first change to the model. >> >> >> >> Long version: >> >> >> >> When an operation mutates either the management Resource tree, or the >> >> registry of capabilities (together known as the management model), we >> >> clone the management model and thereafter that operation works on the >> >> clone. The clone is invisible to other callers until the operations >> >> successfully commits. When the operation commits, it publishes the clone >> >> and that becomes the official model. >> >> >> >> I call this copy-on-write, publish-on-commit. >> >> >> >> If the operation rolls back, the changed model is never published and >> >> the clone is just discarded when the operation execution returns. >> >> >> >> However, while the operation is rolling back, all the >> >> OperationStepHandlers that are processing the rollback see the modified >> >> clone, not the original model. They are seeing arbitrarily incorrect data. >> >> >> >> This hasn't been a problem up to now, as our standard OSHs get a copy of >> >> whatever part of the Resource tree they are going to modify and keep it >> >> for use in rollback. They don't need to re-read the management model to >> >> perform rollback. >> >> >> >> But this doesn't work for the capability registry. If an OSH removes a >> >> capability and removes a service, and then in rollback tries to use the >> >> capability to figure out how to restore the service, it fails, as >> >> management model it can see still shows the capability as being removed. >> >> >> >> To fix this, I propose discarding the cloned management model as soon as >> >> rollback begins. Thereafter, an OSH processing rollback will see the >> >> model as it was before the first modification. The removed capability >> >> will still be present. >> >> >> >> I have a commit that does this at [1]. Running the testsuite with it >> >> shows no regressions. This doesn't surprise me, as our standard OSHs up >> >> to now have had no need to re-read the model during rollback. >> >> >> >> [1] >> >> https://github.com/bstansberry/wildfly-core/commit/419f350931d5b7e345cf9aa514de08c01bf976be >> >> >> >> -- >> >> Brian Stansberry >> >> Senior Principal Software Engineer >> >> JBoss by Red Hat >> >> _______________________________________________ >> >> wildfly-dev mailing list >> >> wildfly-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> > -- >> > Jason T. Greene >> > WildFly Lead / JBoss EAP Platform Architect >> > JBoss, a division of Red Hat >> > >> > >> > _______________________________________________ >> > 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/20150702/36576247/attachment.html From fjuma at redhat.com Thu Jul 2 09:44:53 2015 From: fjuma at redhat.com (Farah Juma) Date: Thu, 2 Jul 2015 09:44:53 -0400 (EDT) Subject: [wildfly-dev] WildFly 10.0.0.Alpha4 is now on OpenShift In-Reply-To: <1716498902.23626964.1435844238789.JavaMail.zimbra@redhat.com> Message-ID: <1513654611.23629612.1435844693219.JavaMail.zimbra@redhat.com> Details for getting started are in the usual place: https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-10 From stian at redhat.com Fri Jul 3 07:40:49 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 3 Jul 2015 07:40:49 -0400 (EDT) Subject: [wildfly-dev] Including Keycloak client adapters in WildFly 10 In-Reply-To: <471812210.31708102.1435923147793.JavaMail.zimbra@redhat.com> Message-ID: <2083988224.31710463.1435923649086.JavaMail.zimbra@redhat.com> Keycloak provides an adapter, including a WildFly extensions, to make it easier to add authentication to JavaEE applications with Keycloak. It includes a few modules. Currently 8 Keycloak specific modules and one 1 third-party. The third-party is net.iharder.base64. As the WildFly extensions includes a deployment processor that configures the authentication method as well as dependencies for a deployment it's easy to add authentication to a JavaEE application. All you need to do is specify it in standalone.xml, for example: ... myrealm MIIBIjAN... http://localhost:8081/auth EXTERNAL mywar 675356d8-2b6b-4602-a74f-7079e0555885 ... I'd like to explore if we can add this extension and the required modules directly to WildFly 10, rather than require users to add it themselves. From tomaz.cerar at gmail.com Fri Jul 3 09:57:09 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 3 Jul 2015 15:57:09 +0200 Subject: [wildfly-dev] Wildfly 9 BOM changes In-Reply-To: <55916C8C.5060508@redhat.com> References: <55916C8C.5060508@redhat.com> Message-ID: Just an update on this, as we discussed it with Thomas on IRC. Result are fixed boms that ware just released with version of 9.0.0.Final that is also in sync with just released WildFly 9.0.0.Final deps. -- tomaz On Mon, Jun 29, 2015 at 6:04 PM, Thomas Segismont wrote: > Hi everyone, > > While working on upgrading Hawkular to Wildfly 9 CR2, we have noticed > that the Wildfly BOM now declares provided scope for some dependencies. > > I guess the goal is to help users which forget to set the provided scope > in their POM to end up with all the libraries in their WAR. > > On the other hand, if you use some libraries in your tests, then > dependency resolution can be broken. For example, if you add > org.jboss.resteasy::resteasy-client in test scope, your tests fail due > to a missing class from commons-io, because commons-io should be > resolved as a transitive dependency of > org.jboss.resteasy::resteasy-jaxrs, but it's now in scope provided, > instead of test. > > Have you considered this use case? Are there other motivations than > helping Maven beginners? > > Best regards, > Thomas > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150703/10a8bc21/attachment.html From tsegismo at redhat.com Fri Jul 3 10:00:34 2015 From: tsegismo at redhat.com (Thomas Segismont) Date: Fri, 03 Jul 2015 16:00:34 +0200 Subject: [wildfly-dev] Wildfly 9 BOM changes In-Reply-To: References: <55916C8C.5060508@redhat.com> Message-ID: <55969582.6010300@redhat.com> Thank you very much Toma?! Le 03/07/2015 15:57, Toma? Cerar a ?crit : > Just an update on this, as we discussed it with Thomas on IRC. > > Result are fixed boms that ware just released with version of 9.0.0.Final > that is also in sync with just released WildFly 9.0.0.Final deps. > > -- > tomaz > > On Mon, Jun 29, 2015 at 6:04 PM, Thomas Segismont > wrote: > > Hi everyone, > > While working on upgrading Hawkular to Wildfly 9 CR2, we have noticed > that the Wildfly BOM now declares provided scope for some dependencies. > > I guess the goal is to help users which forget to set the provided scope > in their POM to end up with all the libraries in their WAR. > > On the other hand, if you use some libraries in your tests, then > dependency resolution can be broken. For example, if you add > org.jboss.resteasy::resteasy-client in test scope, your tests fail due > to a missing class from commons-io, because commons-io should be > resolved as a transitive dependency of > org.jboss.resteasy::resteasy-jaxrs, but it's now in scope provided, > instead of test. > > Have you considered this use case? Are there other motivations than > helping Maven beginners? > > Best regards, > Thomas > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > From rory.odonnell at oracle.com Fri Jul 3 10:23:34 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 03 Jul 2015 15:23:34 +0100 Subject: [wildfly-dev] Early Access builds for JDK 8u60 b21 and JDK 9 b70 are available on java.net Message-ID: <55969AE6.1060301@oracle.com> Hi Jason/Tomaz, Early Access build for JDK 8u60 b21 is available on java.net, summary of changes are listed here. As we enter the later phases of development for JDK 8u60, please log any show stoppers as soon as possible. Early Access build for JDK 9 b70 is available on java.net, summary of changes are listed here . The JDK 9 schedule of record is available on the JDK 9 Project page: http://openjdk.java.net/projects/jdk9 At https://wiki.openjdk.java.net/display/Adoption/JDK+9+Outreach you can find a (preliminary) list of other changes that might affect your project's code in JDK 9, and other things to consider when testing with JDK 9. I'd be curious to know if there is anything on that list you'd consider to have an effect on your project. Please keep in mind that as JEPs and others changes are integrated into (or out of) JDK 9, the list will change over time. 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/20150703/ed99bce8/attachment-0001.html From fjuma at redhat.com Fri Jul 3 14:16:15 2015 From: fjuma at redhat.com (Farah Juma) Date: Fri, 3 Jul 2015 14:16:15 -0400 (EDT) Subject: [wildfly-dev] WildFly 9 Final is now on OpenShift In-Reply-To: <1492975010.23910868.1435946361887.JavaMail.zimbra@redhat.com> Message-ID: <1062306985.23911578.1435947375229.JavaMail.zimbra@redhat.com> See https://developer.jboss.org/people/fjuma/blog/2015/07/03/wildfly-9-final-on-openshift for details on how to get started. Enjoy! From brian.stansberry at redhat.com Fri Jul 3 16:05:07 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 03 Jul 2015 15:05:07 -0500 Subject: [wildfly-dev] Capability naming conventions In-Reply-To: <55841B34.9070801@redhat.com> References: <557B3F78.1090907@redhat.com> <557B4E27.4080708@redhat.com> <557B4F9C.1090200@redhat.com> <21E52078-A52B-4C9E-AA27-B6D4DC088D14@jboss.com> <55831BE7.60207@redhat.com> <578110CB-B5F7-4B5D-AA50-5EBD160167B0@redhat.com> <55841B34.9070801@redhat.com> Message-ID: <5596EAF3.5040109@redhat.com> Status update: I've done the adoc thing and made the repo official by cloning it from my personal github to the wildfly account: https://github.com/wildfly/wildfly-capabilities Further updates should be done via pull requests there. On 6/19/15 8:37 AM, Brian Stansberry wrote: > Thanks; that's a good idea. > > On 6/19/15 8:18 AM, Max Rydahl Andersen wrote: >> Just one quick suggestion. >> >> Instead of .txt, use .adoc then it will actually render nicely on github >> out-of-box and you get access to >> do tables and lists etc. in something that is readable as text and look >> nice rendered. >> >> /max >> >>> On 6/13/15 4:00 AM, Kabir Khan wrote: >>>> >>>>> On 12 Jun 2015, at 22:31, Brian Stansberry >>>>> wrote: >>>>> >>>>> On 6/12/15 4:24 PM, David M. Lloyd wrote: >>>>> >>>>>> >>>>>> Sounds good to me. I'd like to add that internally, we should make >>>>>> sure >>>>>> we continue to maintain some registry of our org.wildfly name spaces >>>>>> somewhere (maybe even just a git repository would be OK) so we don't >>>>>> conflict among ourselves. >>>>>> >>>>> >>>>> Like a text file per capability, with some doc on the capability in >>>>> the >>>>> file? Files organized in a tree from the names? >>>>> >>>>> That sounds good; much better than some wiki. >>>> +1 >>>> I don?t know enough about this yet to suggest a format, but having it >>>> somewhere in the source is a lot better than a wiki. A wiki brings to >>>> mind that horrible log ids page we used for AS 7. >>> >>> How about this? >>> >>> https://github.com/bstansberry/wildfly-capabilities >>> >>> The README.md explains things pretty clearly. >>> >>> At this point it just has the capabilities currentl in core, including >>> unmerged ones added in the PR at >>> >>> https://github.com/wildfly/wildfly-core/pull/810 >>> >>> That repo has a LICENSE file, which specifies ASL 2.0. I don't know if >>> such a thing is really necessary, or if some other license, like >>> Creative Commons, is more appropriate. >>> >>>>> >>>>> -- >>>>> Brian Stansberry >>>>> Senior Principal Software Engineer >>>>> JBoss by Red Hat >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>> >>> >>> -- >>> Brian Stansberry >>> Senior Principal Software Engineer >>> JBoss by Red Hat >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> /max >> http://about.me/maxandersen > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From smaestri at redhat.com Mon Jul 6 05:59:50 2015 From: smaestri at redhat.com (Stefano Maestri) Date: Mon, 06 Jul 2015 11:59:50 +0200 Subject: [wildfly-dev] WFLYCTL0218: A node is already registered at '/deployment=*/subsystem=datasources/xa-data-source=*/statistics=jdbc' In-Reply-To: <5593DC4E.8060400@redhat.com> References: <558CE76F.5000601@osnanet.de> <5593DC4E.8060400@redhat.com> Message-ID: <559A5196.2050002@redhat.com> I've finally reproduced it and created an issue (already sent PR) https://issues.jboss.org/browse/WFLY-4869 regards S. On 07/01/2015 02:25 PM, Stefano Maestri wrote: > Can you give me configuration/step to reproduce the bug? > I can't reproduce it locally. I've probably found the possible cause, > but I'd like to verify it reproducing bug > > best regards > S. > > On 06/26/2015 07:47 AM, Frank Langelage wrote: >> I have a Deja-Vu, I'm very I saw this some months ago. Not it reappears. >> >> Possibly due to the commit #7605 with changes for "WFLY-4429 Refactor >> JCA subsystem". >> >> 26.06. 00:25:37,390 INFO >> [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer#deployXADataSource] >> IJ020018: Enabling for >> java:jboss/datasources/maj2e-langfr-dev >> 26.06. 00:25:37,445 INFO >> [org.jboss.as.connector.subsystems.datasources#transition] WFLYJCA0001: >> Bound data source [java:jboss/datasources/DefaultDS] >> 26.06. 00:25:37,501 INFO >> [org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue] >> IJ020018: Enabling for >> java:/eis/maj2e-langfr-dev/ControllerConnector >> 26.06. 00:25:37,509 INFO >> [org.jboss.as.connector.deployment#bindConnectionFactory] WFLYJCA0007: >> Registered connection factory java:/eis/maj2e-langfr-dev/ControllerConnector >> 26.06. 00:25:37,514 INFO >> [org.jboss.as.connector.deployers.RaXmlDeployer#createObjectsAndInjectValue] >> IJ020002: Deployed: >> file:/mbi/tools/jboss/10.0/standalone/tmp/vfs/temp/temp91b455ac091637f0/content-9d63fac1b393fd1c/contents/ >> 26.06. 00:25:37,801 INFO >> [org.jboss.as.connector.subsystems.datasources#transition] WFLYJCA0001: >> Bound data source [java:jboss/datasources/maj2e-langfr-dev] >> 26.06. 00:25:37,990 ERROR [org.jboss.msc.service.fail#startFailed] >> MSC000001: Failed to start service >> jboss.data-source.java:jboss/datasources/maj2e-langfr-dev.statistics: >> org.jboss.msc.service.StartException in service >> jboss.data-source.java:jboss/datasources/maj2e-langfr-dev.statistics: >> Failed to start service >> at >> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> Caused by: java.lang.IllegalArgumentException: WFLYCTL0218: A node is >> already registered at >> '/deployment=*/subsystem=datasources/xa-data-source=*/statistics=jdbc' >> at >> org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:147) >> at >> org.jboss.as.connector.services.datasources.statistics.DataSourceStatisticsService.start(DataSourceStatisticsService.java:83) >> at >> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) >> at >> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) >> ... 3 more >> >> >> _______________________________________________ >> 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 smaestri at redhat.com Mon Jul 6 09:16:14 2015 From: smaestri at redhat.com (Stefano Maestri) Date: Mon, 06 Jul 2015 15:16:14 +0200 Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers In-Reply-To: References: Message-ID: <559A7F9E.6050100@redhat.com> Hi all, I've probably missed the final decision about that. I've worked on 2 issues last week: - WFLY-4566 Remove support for jboss-as-datasources_1_0.xsd - WFLY-4568 Remove support for jboss-as-resource-adapters_1_0.xsd removing very old xsds. I have a lot of tests failing because we still support 7.x xsds. I would suggest to reopen this discussion and evaluate if and when we are de-supporting them. I'm sorry if a decision was already taken and I've missed or misunderstood that one regards S. On 03/27/2015 12:13 AM, Toma? Cerar wrote: > Hi folks, > > we discussed on team meeting in Brno about dropping support for old > legacy host controllers > when running in mixed domain mode (having DC of newer version managing > older version HCs) > > We also discussed dropping old xsd sachems & parsers as it would help > us cleanup and simplify code > in many subsystems as there are cases where we support and maintain 5 > and more different > versions of parser. For example currently web subsystem has 8, > infinispan 7, ejb & jackorb have 6, ... > We still have parsers that that ware shipped back in 7.0.0 and became > obsolete in later 7.0.x releases. > > Given that we decided that we are dropping support for running mixed > domain mode for host controller > that are older than 7.3.0 (EAP 6.2) as is tracked by > https://issues.jboss.org/browse/WFLY-3564 > > I would also like to suggest that we do the same for xml schemas & > parsers. > > *What is the downside?* > > Automatic upgrading from JBoss AS 7.1.x/EAP < 6.2 version with using > same standalone.xml won't work anymore. > User would need to upgrade to WildFly 8.x and from there to 9 or 10 > (depending when we drop this) > Because of replacement of web subsystem with undertow and introduction > of few other subsystems (io, SM) > this already doesn't work for 7.x-->8+, but we do have plans how to > improve that. > > > So, are there any objections against this? > > -- > Toma? > > > > > > > > > > > _______________________________________________ > 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/20150706/79a275a8/attachment.html From jperkins at redhat.com Mon Jul 6 15:13:14 2015 From: jperkins at redhat.com (James R. Perkins) Date: Mon, 6 Jul 2015 12:13:14 -0700 Subject: [wildfly-dev] Batch Subsystem Changes Message-ID: <559AD34A.5030307@redhat.com> Hello All, The past couple weeks I've been working on basically a redo of the batch subsystem. Almost the entire management model is changing to hopefully make it more user friendly. In WildFly 8 and WildFly 9 the model looked like the following: { "job-repository-type" => "in-memory", "job-repository" => {"jdbc" => {"jndi-name" => undefined}}, "thread-factory" => undefined, "thread-pool" => {"batch" => { "keepalive-time" => { "time" => 30L, "unit" => "SECONDS" }, "max-threads" => 10, "name" => "batch", "thread-factory" => undefined }} } The job-repository-type could either be jdcb or in-memory. The jndi-name attribute on the single job-repository=jdbc resource could be undefined indicating the default data-source should be used or JNDI name to look up the data-source with no validation being done until the user actually tries to deploy a batch deployment. The thread-pool and thread-factory are the same as other resources that use the thread "subsystem" shared resources. As you can see it's not very intuitive and somewhat clumsy to say the least. Only a single job-repository could be defined which isn't great for multiple deployments. In WildFly 10 the model, at least currently, will look like: { "default-job-repository" => "default", "in-memory-job-repository" => {"default" => {}}, "jdbc-job-repository" => {"jdbc" => {"data-source" => "ExampleDS"}}, "thread-factory" => undefined, "thread-pool" => {"batch" => { "active-count" => 0, "completed-task-count" => 0L, "current-thread-count" => 0, "keepalive-time" => { "time" => 30L, "unit" => "SECONDS" }, "largest-thread-count" => 0, "max-threads" => 10, "name" => "batch", "queue-size" => 0, "rejected-count" => 0, "task-count" => 0L, "thread-factory" => undefined }} } The default-job-repository will be an attribute similar to the previous job-repository attribute. The difference being you can use any named in-memory-job-repository or jdbc-job-repository. You can have any number of in-memory or JDBC job repositories. The data-source attribute value on a jdbc-job-repository resource will use the org.wildfly.data-source [1]. The name of the data-source is used instead of the JNDI which is a much cleaner approach. The thread-factory may be removed and the thread-pool may be changed to use attribute groups (once I figure out how to use them :)). As part of this I considered changing the name from batch to batch-jberet. The main concern I had with this was the web console, but I seem to have broken that anyway with the changes to the model. Does anyone have opinions on a name change to batch-jberet? Also parsing an old configuration may have some issues if the user was using a JDBC job repository. I've currently not found a good way to find a data-source resource name based on a JNDI name. I'm not sure if we should just fail when adding a legacy JDBC job repository. Any suggestions here would be helpful. Any comments or concerns in general are welcome. This is our chance to get it right this time. [1]: https://github.com/wildfly/wildfly/pull/7682 -- James R. Perkins JBoss by Red Hat From brian.stansberry at redhat.com Mon Jul 6 17:29:11 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 06 Jul 2015 16:29:11 -0500 Subject: [wildfly-dev] Dropping legacy XSD schemas & its parsers In-Reply-To: <559A7F9E.6050100@redhat.com> References: <559A7F9E.6050100@redhat.com> Message-ID: <559AF327.4050700@redhat.com> This post from Tomaz summarized where the discussion ended up: http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003783.html So, jboss-as-resource-adapters_1_0.xsd can't be dropped. The jboss-as-datasources_1_0.xsd could be dropped, and the ParseAndMarshalModelsTestCase.test710... and test711... tests could be removed. The tests712 ones stay. The datasources PR shows test712... tests failing though. I think the files they are testing against are inaccurate though; they don't match the 7.1.2.Final tag. I'll send up a PR to remove the 710, 711 tests and fix the 712 ones. On 7/6/15 8:16 AM, Stefano Maestri wrote: > Hi all, > > I've probably missed the final decision about that. I've worked on 2 > issues last week: > > - WFLY-4566 Remove support for jboss-as-datasources_1_0.xsd > - WFLY-4568 Remove support for jboss-as-resource-adapters_1_0.xsd > > removing very old xsds. I have a lot of tests failing because we still > support 7.x xsds. > I would suggest to reopen this discussion and evaluate if and when we > are de-supporting them. > > I'm sorry if a decision was already taken and I've missed or > misunderstood that one > > regards > S. > > > On 03/27/2015 12:13 AM, Toma? Cerar wrote: >> Hi folks, >> >> we discussed on team meeting in Brno about dropping support for old >> legacy host controllers >> when running in mixed domain mode (having DC of newer version managing >> older version HCs) >> >> We also discussed dropping old xsd sachems & parsers as it would help >> us cleanup and simplify code >> in many subsystems as there are cases where we support and maintain 5 >> and more different >> versions of parser. For example currently web subsystem has 8, >> infinispan 7, ejb & jackorb have 6, ... >> We still have parsers that that ware shipped back in 7.0.0 and became >> obsolete in later 7.0.x releases. >> >> Given that we decided that we are dropping support for running mixed >> domain mode for host controller >> that are older than 7.3.0 (EAP 6.2) as is tracked by >> https://issues.jboss.org/browse/WFLY-3564 >> >> I would also like to suggest that we do the same for xml schemas & >> parsers. >> >> *What is the downside?* >> >> Automatic upgrading from JBoss AS 7.1.x/EAP < 6.2 version with using >> same standalone.xml won't work anymore. >> User would need to upgrade to WildFly 8.x and from there to 9 or 10 >> (depending when we drop this) >> Because of replacement of web subsystem with undertow and introduction >> of few other subsystems (io, SM) >> this already doesn't work for 7.x-->8+, but we do have plans how to >> improve that. >> >> >> So, are there any objections against this? >> >> -- >> Toma? >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jason.greene at redhat.com Mon Jul 6 21:02:18 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Mon, 6 Jul 2015 21:02:18 -0400 (EDT) Subject: [wildfly-dev] Batch Subsystem Changes In-Reply-To: <559AD34A.5030307@redhat.com> References: <559AD34A.5030307@redhat.com> Message-ID: <935169A4-623C-4561-B0AA-9AFE1989E27F@redhat.com> IMO we should avoid breaking compatibility unless there is no other option. If we do break compatibility we should rename the subsystem and provide a migration operation. > On Jul 6, 2015, at 2:13 PM, James R. Perkins wrote: > > Hello All, > The past couple weeks I've been working on basically a redo of the batch > subsystem. Almost the entire management model is changing to hopefully > make it more user friendly. > > In WildFly 8 and WildFly 9 the model looked like the following: > > { > "job-repository-type" => "in-memory", > "job-repository" => {"jdbc" => {"jndi-name" => undefined}}, > "thread-factory" => undefined, > "thread-pool" => {"batch" => { > "keepalive-time" => { > "time" => 30L, > "unit" => "SECONDS" > }, > "max-threads" => 10, > "name" => "batch", > "thread-factory" => undefined > }} > } > > The job-repository-type could either be jdcb or in-memory. The jndi-name > attribute on the single job-repository=jdbc resource could be undefined > indicating the default data-source should be used or JNDI name to look > up the data-source with no validation being done until the user actually > tries to deploy a batch deployment. > > The thread-pool and thread-factory are the same as other resources that > use the thread "subsystem" shared resources. > > As you can see it's not very intuitive and somewhat clumsy to say the > least. Only a single job-repository could be defined which isn't great > for multiple deployments. > > In WildFly 10 the model, at least currently, will look like: > > { > "default-job-repository" => "default", > "in-memory-job-repository" => {"default" => {}}, > "jdbc-job-repository" => {"jdbc" => {"data-source" => "ExampleDS"}}, > "thread-factory" => undefined, > "thread-pool" => {"batch" => { > "active-count" => 0, > "completed-task-count" => 0L, > "current-thread-count" => 0, > "keepalive-time" => { > "time" => 30L, > "unit" => "SECONDS" > }, > "largest-thread-count" => 0, > "max-threads" => 10, > "name" => "batch", > "queue-size" => 0, > "rejected-count" => 0, > "task-count" => 0L, > "thread-factory" => undefined > }} > } > > The default-job-repository will be an attribute similar to the previous > job-repository attribute. The difference being you can use any named > in-memory-job-repository or jdbc-job-repository. You can have any number > of in-memory or JDBC job repositories. > > The data-source attribute value on a jdbc-job-repository resource will > use the org.wildfly.data-source [1]. The name of the data-source is used > instead of the JNDI which is a much cleaner approach. > > The thread-factory may be removed and the thread-pool may be changed to > use attribute groups (once I figure out how to use them :)). > > As part of this I considered changing the name from batch to > batch-jberet. The main concern I had with this was the web console, but > I seem to have broken that anyway with the changes to the model. Does > anyone have opinions on a name change to batch-jberet? > > Also parsing an old configuration may have some issues if the user was > using a JDBC job repository. I've currently not found a good way to find > a data-source resource name based on a JNDI name. I'm not sure if we > should just fail when adding a legacy JDBC job repository. Any > suggestions here would be helpful. > > Any comments or concerns in general are welcome. This is our chance to > get it right this time. > > > [1]: https://github.com/wildfly/wildfly/pull/7682 > > -- > 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 jason.greene at redhat.com Mon Jul 6 21:05:51 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Mon, 6 Jul 2015 21:05:51 -0400 (EDT) Subject: [wildfly-dev] Batch Subsystem Changes In-Reply-To: <935169A4-623C-4561-B0AA-9AFE1989E27F@redhat.com> References: <559AD34A.5030307@redhat.com> <935169A4-623C-4561-B0AA-9AFE1989E27F@redhat.com> Message-ID: <86569ED0-5546-42BA-B753-251FC4279578@redhat.com> Actually in this case you could support both the old and the new subsystem as its a one to one mapping. Then you do not need the migration bit. Sent from my iPhone > On Jul 6, 2015, at 8:02 PM, Jason T. Greene wrote: > > IMO we should avoid breaking compatibility unless there is no other option. If we do break compatibility we should rename the subsystem and provide a migration operation. > >> On Jul 6, 2015, at 2:13 PM, James R. Perkins wrote: >> >> Hello All, >> The past couple weeks I've been working on basically a redo of the batch >> subsystem. Almost the entire management model is changing to hopefully >> make it more user friendly. >> >> In WildFly 8 and WildFly 9 the model looked like the following: >> >> { >> "job-repository-type" => "in-memory", >> "job-repository" => {"jdbc" => {"jndi-name" => undefined}}, >> "thread-factory" => undefined, >> "thread-pool" => {"batch" => { >> "keepalive-time" => { >> "time" => 30L, >> "unit" => "SECONDS" >> }, >> "max-threads" => 10, >> "name" => "batch", >> "thread-factory" => undefined >> }} >> } >> >> The job-repository-type could either be jdcb or in-memory. The jndi-name >> attribute on the single job-repository=jdbc resource could be undefined >> indicating the default data-source should be used or JNDI name to look >> up the data-source with no validation being done until the user actually >> tries to deploy a batch deployment. >> >> The thread-pool and thread-factory are the same as other resources that >> use the thread "subsystem" shared resources. >> >> As you can see it's not very intuitive and somewhat clumsy to say the >> least. Only a single job-repository could be defined which isn't great >> for multiple deployments. >> >> In WildFly 10 the model, at least currently, will look like: >> >> { >> "default-job-repository" => "default", >> "in-memory-job-repository" => {"default" => {}}, >> "jdbc-job-repository" => {"jdbc" => {"data-source" => "ExampleDS"}}, >> "thread-factory" => undefined, >> "thread-pool" => {"batch" => { >> "active-count" => 0, >> "completed-task-count" => 0L, >> "current-thread-count" => 0, >> "keepalive-time" => { >> "time" => 30L, >> "unit" => "SECONDS" >> }, >> "largest-thread-count" => 0, >> "max-threads" => 10, >> "name" => "batch", >> "queue-size" => 0, >> "rejected-count" => 0, >> "task-count" => 0L, >> "thread-factory" => undefined >> }} >> } >> >> The default-job-repository will be an attribute similar to the previous >> job-repository attribute. The difference being you can use any named >> in-memory-job-repository or jdbc-job-repository. You can have any number >> of in-memory or JDBC job repositories. >> >> The data-source attribute value on a jdbc-job-repository resource will >> use the org.wildfly.data-source [1]. The name of the data-source is used >> instead of the JNDI which is a much cleaner approach. >> >> The thread-factory may be removed and the thread-pool may be changed to >> use attribute groups (once I figure out how to use them :)). >> >> As part of this I considered changing the name from batch to >> batch-jberet. The main concern I had with this was the web console, but >> I seem to have broken that anyway with the changes to the model. Does >> anyone have opinions on a name change to batch-jberet? >> >> Also parsing an old configuration may have some issues if the user was >> using a JDBC job repository. I've currently not found a good way to find >> a data-source resource name based on a JNDI name. I'm not sure if we >> should just fail when adding a legacy JDBC job repository. Any >> suggestions here would be helpful. >> >> Any comments or concerns in general are welcome. This is our chance to >> get it right this time. >> >> >> [1]: https://github.com/wildfly/wildfly/pull/7682 >> >> -- >> 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 cfang at redhat.com Mon Jul 6 22:31:13 2015 From: cfang at redhat.com (Cheng Fang) Date: Mon, 06 Jul 2015 22:31:13 -0400 Subject: [wildfly-dev] Batch Subsystem Changes In-Reply-To: <559AD34A.5030307@redhat.com> References: <559AD34A.5030307@redhat.com> Message-ID: <559B39F1.6050502@redhat.com> How does it support adding new types of job repository (e.g., infinispan job repository) in the future? Cheng On 7/6/15 3:13 PM, James R. Perkins wrote: > Hello All, > The past couple weeks I've been working on basically a redo of the batch > subsystem. Almost the entire management model is changing to hopefully > make it more user friendly. > > In WildFly 8 and WildFly 9 the model looked like the following: > > { > "job-repository-type" => "in-memory", > "job-repository" => {"jdbc" => {"jndi-name" => undefined}}, > "thread-factory" => undefined, > "thread-pool" => {"batch" => { > "keepalive-time" => { > "time" => 30L, > "unit" => "SECONDS" > }, > "max-threads" => 10, > "name" => "batch", > "thread-factory" => undefined > }} > } > > The job-repository-type could either be jdcb or in-memory. The jndi-name > attribute on the single job-repository=jdbc resource could be undefined > indicating the default data-source should be used or JNDI name to look > up the data-source with no validation being done until the user actually > tries to deploy a batch deployment. > > The thread-pool and thread-factory are the same as other resources that > use the thread "subsystem" shared resources. > > As you can see it's not very intuitive and somewhat clumsy to say the > least. Only a single job-repository could be defined which isn't great > for multiple deployments. > > In WildFly 10 the model, at least currently, will look like: > > { > "default-job-repository" => "default", > "in-memory-job-repository" => {"default" => {}}, > "jdbc-job-repository" => {"jdbc" => {"data-source" => "ExampleDS"}}, > "thread-factory" => undefined, > "thread-pool" => {"batch" => { > "active-count" => 0, > "completed-task-count" => 0L, > "current-thread-count" => 0, > "keepalive-time" => { > "time" => 30L, > "unit" => "SECONDS" > }, > "largest-thread-count" => 0, > "max-threads" => 10, > "name" => "batch", > "queue-size" => 0, > "rejected-count" => 0, > "task-count" => 0L, > "thread-factory" => undefined > }} > } > > The default-job-repository will be an attribute similar to the previous > job-repository attribute. The difference being you can use any named > in-memory-job-repository or jdbc-job-repository. You can have any number > of in-memory or JDBC job repositories. > > The data-source attribute value on a jdbc-job-repository resource will > use the org.wildfly.data-source [1]. The name of the data-source is used > instead of the JNDI which is a much cleaner approach. > > The thread-factory may be removed and the thread-pool may be changed to > use attribute groups (once I figure out how to use them :)). > > As part of this I considered changing the name from batch to > batch-jberet. The main concern I had with this was the web console, but > I seem to have broken that anyway with the changes to the model. Does > anyone have opinions on a name change to batch-jberet? > > Also parsing an old configuration may have some issues if the user was > using a JDBC job repository. I've currently not found a good way to find > a data-source resource name based on a JNDI name. I'm not sure if we > should just fail when adding a legacy JDBC job repository. Any > suggestions here would be helpful. > > Any comments or concerns in general are welcome. This is our chance to > get it right this time. > > > [1]: https://github.com/wildfly/wildfly/pull/7682 > From darran.lofthouse at jboss.com Tue Jul 7 07:10:48 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 07 Jul 2015 12:10:48 +0100 Subject: [wildfly-dev] Batch Subsystem Changes In-Reply-To: <559B39F1.6050502@redhat.com> References: <559AD34A.5030307@redhat.com> <559B39F1.6050502@redhat.com> Message-ID: <559BB3B8.7040108@jboss.com> Related to that - how does this fit with capabilities and requirements? Could other subsystems register their own job repository or does this all need to happen within the batch subsystem? On 07/07/15 03:31, Cheng Fang wrote: > How does it support adding new types of job repository (e.g., infinispan > job repository) in the future? > > Cheng > > On 7/6/15 3:13 PM, James R. Perkins wrote: >> Hello All, >> The past couple weeks I've been working on basically a redo of the batch >> subsystem. Almost the entire management model is changing to hopefully >> make it more user friendly. >> >> In WildFly 8 and WildFly 9 the model looked like the following: >> >> { >> "job-repository-type" => "in-memory", >> "job-repository" => {"jdbc" => {"jndi-name" => undefined}}, >> "thread-factory" => undefined, >> "thread-pool" => {"batch" => { >> "keepalive-time" => { >> "time" => 30L, >> "unit" => "SECONDS" >> }, >> "max-threads" => 10, >> "name" => "batch", >> "thread-factory" => undefined >> }} >> } >> >> The job-repository-type could either be jdcb or in-memory. The jndi-name >> attribute on the single job-repository=jdbc resource could be undefined >> indicating the default data-source should be used or JNDI name to look >> up the data-source with no validation being done until the user actually >> tries to deploy a batch deployment. >> >> The thread-pool and thread-factory are the same as other resources that >> use the thread "subsystem" shared resources. >> >> As you can see it's not very intuitive and somewhat clumsy to say the >> least. Only a single job-repository could be defined which isn't great >> for multiple deployments. >> >> In WildFly 10 the model, at least currently, will look like: >> >> { >> "default-job-repository" => "default", >> "in-memory-job-repository" => {"default" => {}}, >> "jdbc-job-repository" => {"jdbc" => {"data-source" => "ExampleDS"}}, >> "thread-factory" => undefined, >> "thread-pool" => {"batch" => { >> "active-count" => 0, >> "completed-task-count" => 0L, >> "current-thread-count" => 0, >> "keepalive-time" => { >> "time" => 30L, >> "unit" => "SECONDS" >> }, >> "largest-thread-count" => 0, >> "max-threads" => 10, >> "name" => "batch", >> "queue-size" => 0, >> "rejected-count" => 0, >> "task-count" => 0L, >> "thread-factory" => undefined >> }} >> } >> >> The default-job-repository will be an attribute similar to the previous >> job-repository attribute. The difference being you can use any named >> in-memory-job-repository or jdbc-job-repository. You can have any number >> of in-memory or JDBC job repositories. >> >> The data-source attribute value on a jdbc-job-repository resource will >> use the org.wildfly.data-source [1]. The name of the data-source is used >> instead of the JNDI which is a much cleaner approach. >> >> The thread-factory may be removed and the thread-pool may be changed to >> use attribute groups (once I figure out how to use them :)). >> >> As part of this I considered changing the name from batch to >> batch-jberet. The main concern I had with this was the web console, but >> I seem to have broken that anyway with the changes to the model. Does >> anyone have opinions on a name change to batch-jberet? >> >> Also parsing an old configuration may have some issues if the user was >> using a JDBC job repository. I've currently not found a good way to find >> a data-source resource name based on a JNDI name. I'm not sure if we >> should just fail when adding a legacy JDBC job repository. Any >> suggestions here would be helpful. >> >> Any comments or concerns in general are welcome. This is our chance to >> get it right this time. >> >> >> [1]: https://github.com/wildfly/wildfly/pull/7682 >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From jperkins at redhat.com Tue Jul 7 11:57:19 2015 From: jperkins at redhat.com (James R. Perkins) Date: Tue, 7 Jul 2015 08:57:19 -0700 Subject: [wildfly-dev] Batch Subsystem Changes In-Reply-To: <86569ED0-5546-42BA-B753-251FC4279578@redhat.com> References: <559AD34A.5030307@redhat.com> <935169A4-623C-4561-B0AA-9AFE1989E27F@redhat.com> <86569ED0-5546-42BA-B753-251FC4279578@redhat.com> Message-ID: <559BF6DF.6030307@redhat.com> Yeah that's definitely an option. One of the biggest issues with the current model is the JNDI name can't be validated. In a perfect world I'd definitely not like to change the model. However my original design of the model was rather poor. Since there will be other subsystems changing in WildFly 10 I thought now would be the right time to break if we're going to break it at all. On 07/06/2015 06:05 PM, Jason T. Greene wrote: > Actually in this case you could support both the old and the new subsystem as its a one to one mapping. Then you do not need the migration bit. > > Sent from my iPhone > >> On Jul 6, 2015, at 8:02 PM, Jason T. Greene wrote: >> >> IMO we should avoid breaking compatibility unless there is no other option. If we do break compatibility we should rename the subsystem and provide a migration operation. >> >>> On Jul 6, 2015, at 2:13 PM, James R. Perkins wrote: >>> >>> Hello All, >>> The past couple weeks I've been working on basically a redo of the batch >>> subsystem. Almost the entire management model is changing to hopefully >>> make it more user friendly. >>> >>> In WildFly 8 and WildFly 9 the model looked like the following: >>> >>> { >>> "job-repository-type" => "in-memory", >>> "job-repository" => {"jdbc" => {"jndi-name" => undefined}}, >>> "thread-factory" => undefined, >>> "thread-pool" => {"batch" => { >>> "keepalive-time" => { >>> "time" => 30L, >>> "unit" => "SECONDS" >>> }, >>> "max-threads" => 10, >>> "name" => "batch", >>> "thread-factory" => undefined >>> }} >>> } >>> >>> The job-repository-type could either be jdcb or in-memory. The jndi-name >>> attribute on the single job-repository=jdbc resource could be undefined >>> indicating the default data-source should be used or JNDI name to look >>> up the data-source with no validation being done until the user actually >>> tries to deploy a batch deployment. >>> >>> The thread-pool and thread-factory are the same as other resources that >>> use the thread "subsystem" shared resources. >>> >>> As you can see it's not very intuitive and somewhat clumsy to say the >>> least. Only a single job-repository could be defined which isn't great >>> for multiple deployments. >>> >>> In WildFly 10 the model, at least currently, will look like: >>> >>> { >>> "default-job-repository" => "default", >>> "in-memory-job-repository" => {"default" => {}}, >>> "jdbc-job-repository" => {"jdbc" => {"data-source" => "ExampleDS"}}, >>> "thread-factory" => undefined, >>> "thread-pool" => {"batch" => { >>> "active-count" => 0, >>> "completed-task-count" => 0L, >>> "current-thread-count" => 0, >>> "keepalive-time" => { >>> "time" => 30L, >>> "unit" => "SECONDS" >>> }, >>> "largest-thread-count" => 0, >>> "max-threads" => 10, >>> "name" => "batch", >>> "queue-size" => 0, >>> "rejected-count" => 0, >>> "task-count" => 0L, >>> "thread-factory" => undefined >>> }} >>> } >>> >>> The default-job-repository will be an attribute similar to the previous >>> job-repository attribute. The difference being you can use any named >>> in-memory-job-repository or jdbc-job-repository. You can have any number >>> of in-memory or JDBC job repositories. >>> >>> The data-source attribute value on a jdbc-job-repository resource will >>> use the org.wildfly.data-source [1]. The name of the data-source is used >>> instead of the JNDI which is a much cleaner approach. >>> >>> The thread-factory may be removed and the thread-pool may be changed to >>> use attribute groups (once I figure out how to use them :)). >>> >>> As part of this I considered changing the name from batch to >>> batch-jberet. The main concern I had with this was the web console, but >>> I seem to have broken that anyway with the changes to the model. Does >>> anyone have opinions on a name change to batch-jberet? >>> >>> Also parsing an old configuration may have some issues if the user was >>> using a JDBC job repository. I've currently not found a good way to find >>> a data-source resource name based on a JNDI name. I'm not sure if we >>> should just fail when adding a legacy JDBC job repository. Any >>> suggestions here would be helpful. >>> >>> Any comments or concerns in general are welcome. This is our chance to >>> get it right this time. >>> >>> >>> [1]: https://github.com/wildfly/wildfly/pull/7682 >>> >>> -- >>> 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 -- James R. Perkins JBoss by Red Hat From jperkins at redhat.com Tue Jul 7 11:58:11 2015 From: jperkins at redhat.com (James R. Perkins) Date: Tue, 7 Jul 2015 08:58:11 -0700 Subject: [wildfly-dev] Batch Subsystem Changes In-Reply-To: <559B39F1.6050502@redhat.com> References: <559AD34A.5030307@redhat.com> <559B39F1.6050502@redhat.com> Message-ID: <559BF713.9070407@redhat.com> On 07/06/2015 07:31 PM, Cheng Fang wrote: > How does it support adding new types of job repository (e.g., infinispan > job repository) in the future? They would just be new resources on the subsystem. So for infinispan we'd just have an infinispan-job-repository resource. > > Cheng > > On 7/6/15 3:13 PM, James R. Perkins wrote: >> Hello All, >> The past couple weeks I've been working on basically a redo of the batch >> subsystem. Almost the entire management model is changing to hopefully >> make it more user friendly. >> >> In WildFly 8 and WildFly 9 the model looked like the following: >> >> { >> "job-repository-type" => "in-memory", >> "job-repository" => {"jdbc" => {"jndi-name" => undefined}}, >> "thread-factory" => undefined, >> "thread-pool" => {"batch" => { >> "keepalive-time" => { >> "time" => 30L, >> "unit" => "SECONDS" >> }, >> "max-threads" => 10, >> "name" => "batch", >> "thread-factory" => undefined >> }} >> } >> >> The job-repository-type could either be jdcb or in-memory. The jndi-name >> attribute on the single job-repository=jdbc resource could be undefined >> indicating the default data-source should be used or JNDI name to look >> up the data-source with no validation being done until the user actually >> tries to deploy a batch deployment. >> >> The thread-pool and thread-factory are the same as other resources that >> use the thread "subsystem" shared resources. >> >> As you can see it's not very intuitive and somewhat clumsy to say the >> least. Only a single job-repository could be defined which isn't great >> for multiple deployments. >> >> In WildFly 10 the model, at least currently, will look like: >> >> { >> "default-job-repository" => "default", >> "in-memory-job-repository" => {"default" => {}}, >> "jdbc-job-repository" => {"jdbc" => {"data-source" => "ExampleDS"}}, >> "thread-factory" => undefined, >> "thread-pool" => {"batch" => { >> "active-count" => 0, >> "completed-task-count" => 0L, >> "current-thread-count" => 0, >> "keepalive-time" => { >> "time" => 30L, >> "unit" => "SECONDS" >> }, >> "largest-thread-count" => 0, >> "max-threads" => 10, >> "name" => "batch", >> "queue-size" => 0, >> "rejected-count" => 0, >> "task-count" => 0L, >> "thread-factory" => undefined >> }} >> } >> >> The default-job-repository will be an attribute similar to the previous >> job-repository attribute. The difference being you can use any named >> in-memory-job-repository or jdbc-job-repository. You can have any number >> of in-memory or JDBC job repositories. >> >> The data-source attribute value on a jdbc-job-repository resource will >> use the org.wildfly.data-source [1]. The name of the data-source is used >> instead of the JNDI which is a much cleaner approach. >> >> The thread-factory may be removed and the thread-pool may be changed to >> use attribute groups (once I figure out how to use them :)). >> >> As part of this I considered changing the name from batch to >> batch-jberet. The main concern I had with this was the web console, but >> I seem to have broken that anyway with the changes to the model. Does >> anyone have opinions on a name change to batch-jberet? >> >> Also parsing an old configuration may have some issues if the user was >> using a JDBC job repository. I've currently not found a good way to find >> a data-source resource name based on a JNDI name. I'm not sure if we >> should just fail when adding a legacy JDBC job repository. Any >> suggestions here would be helpful. >> >> Any comments or concerns in general are welcome. This is our chance to >> get it right this time. >> >> >> [1]: https://github.com/wildfly/wildfly/pull/7682 >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- James R. Perkins JBoss by Red Hat From jperkins at redhat.com Tue Jul 7 11:59:20 2015 From: jperkins at redhat.com (James R. Perkins) Date: Tue, 7 Jul 2015 08:59:20 -0700 Subject: [wildfly-dev] Batch Subsystem Changes In-Reply-To: <559BB3B8.7040108@jboss.com> References: <559AD34A.5030307@redhat.com> <559B39F1.6050502@redhat.com> <559BB3B8.7040108@jboss.com> Message-ID: <559BF758.9090704@redhat.com> On 07/07/2015 04:10 AM, Darran Lofthouse wrote: > Related to that - how does this fit with capabilities and requirements? > Could other subsystems register their own job repository or does this > all need to happen within the batch subsystem? That's an interesting idea I hadn't thought of. It should work though as I am using a dynamic capability for the job repository. > > On 07/07/15 03:31, Cheng Fang wrote: >> How does it support adding new types of job repository (e.g., infinispan >> job repository) in the future? >> >> Cheng >> >> On 7/6/15 3:13 PM, James R. Perkins wrote: >>> Hello All, >>> The past couple weeks I've been working on basically a redo of the batch >>> subsystem. Almost the entire management model is changing to hopefully >>> make it more user friendly. >>> >>> In WildFly 8 and WildFly 9 the model looked like the following: >>> >>> { >>> "job-repository-type" => "in-memory", >>> "job-repository" => {"jdbc" => {"jndi-name" => undefined}}, >>> "thread-factory" => undefined, >>> "thread-pool" => {"batch" => { >>> "keepalive-time" => { >>> "time" => 30L, >>> "unit" => "SECONDS" >>> }, >>> "max-threads" => 10, >>> "name" => "batch", >>> "thread-factory" => undefined >>> }} >>> } >>> >>> The job-repository-type could either be jdcb or in-memory. The jndi-name >>> attribute on the single job-repository=jdbc resource could be undefined >>> indicating the default data-source should be used or JNDI name to look >>> up the data-source with no validation being done until the user actually >>> tries to deploy a batch deployment. >>> >>> The thread-pool and thread-factory are the same as other resources that >>> use the thread "subsystem" shared resources. >>> >>> As you can see it's not very intuitive and somewhat clumsy to say the >>> least. Only a single job-repository could be defined which isn't great >>> for multiple deployments. >>> >>> In WildFly 10 the model, at least currently, will look like: >>> >>> { >>> "default-job-repository" => "default", >>> "in-memory-job-repository" => {"default" => {}}, >>> "jdbc-job-repository" => {"jdbc" => {"data-source" => "ExampleDS"}}, >>> "thread-factory" => undefined, >>> "thread-pool" => {"batch" => { >>> "active-count" => 0, >>> "completed-task-count" => 0L, >>> "current-thread-count" => 0, >>> "keepalive-time" => { >>> "time" => 30L, >>> "unit" => "SECONDS" >>> }, >>> "largest-thread-count" => 0, >>> "max-threads" => 10, >>> "name" => "batch", >>> "queue-size" => 0, >>> "rejected-count" => 0, >>> "task-count" => 0L, >>> "thread-factory" => undefined >>> }} >>> } >>> >>> The default-job-repository will be an attribute similar to the previous >>> job-repository attribute. The difference being you can use any named >>> in-memory-job-repository or jdbc-job-repository. You can have any number >>> of in-memory or JDBC job repositories. >>> >>> The data-source attribute value on a jdbc-job-repository resource will >>> use the org.wildfly.data-source [1]. The name of the data-source is used >>> instead of the JNDI which is a much cleaner approach. >>> >>> The thread-factory may be removed and the thread-pool may be changed to >>> use attribute groups (once I figure out how to use them :)). >>> >>> As part of this I considered changing the name from batch to >>> batch-jberet. The main concern I had with this was the web console, but >>> I seem to have broken that anyway with the changes to the model. Does >>> anyone have opinions on a name change to batch-jberet? >>> >>> Also parsing an old configuration may have some issues if the user was >>> using a JDBC job repository. I've currently not found a good way to find >>> a data-source resource name based on a JNDI name. I'm not sure if we >>> should just fail when adding a legacy JDBC job repository. Any >>> suggestions here would be helpful. >>> >>> Any comments or concerns in general are welcome. This is our chance to >>> get it right this time. >>> >>> >>> [1]: https://github.com/wildfly/wildfly/pull/7682 >>> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- James R. Perkins JBoss by Red Hat From mgandikota at westechmed.com Tue Jul 7 15:27:11 2015 From: mgandikota at westechmed.com (Gandikota, Murthy) Date: Tue, 7 Jul 2015 19:27:11 +0000 Subject: [wildfly-dev] CreateProcess error=206, The filename or extension is too long Message-ID: <300155EADBAD7948B33FE136A4BF600D4EE1EBBE@oma04cexch01.westdevinc.com> Hi All Getting this error on Windows 7. The command runs fine on Linux CreateProcess error=206, The filename or extension is too long Please view this link for the full classpath given to java: http://www.java-forums.org/apache-maven/87771-createprocess-error-206-filename-extension-too-long.html The above is a fairly old post (April, 2014). Things may have changed in the mean time (the wheel of technology never stops, except for MS:) I'd grateful for any help. Best regards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150707/5d7564e4/attachment.html From eduardo.santanadasilva at gmail.com Tue Jul 7 15:58:17 2015 From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva) Date: Tue, 7 Jul 2015 16:58:17 -0300 Subject: [wildfly-dev] CreateProcess error=206, The filename or extension is too long In-Reply-To: <300155EADBAD7948B33FE136A4BF600D4EE1EBBE@oma04cexch01.westdevinc.com> References: <300155EADBAD7948B33FE136A4BF600D4EE1EBBE@oma04cexch01.westdevinc.com> Message-ID: Could you provide more information? What is your JDK version? Jboss/Wildfly version? I found a similar issue but was solved a long time ago: https://issues.jboss.org/browse/JBTIS-101 On Jul 7, 2015, at 4:27 PM, Gandikota, Murthy wrote: > CreateProcess error=206, The filename or extension is too long > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150707/e10ce692/attachment.html From tomaz.cerar at gmail.com Tue Jul 7 16:21:18 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Tue, 7 Jul 2015 22:21:18 +0200 Subject: [wildfly-dev] CreateProcess error=206, The filename or extension is too long In-Reply-To: <300155EADBAD7948B33FE136A4BF600D4EE1EBBE@oma04cexch01.westdevinc.com> References: <300155EADBAD7948B33FE136A4BF600D4EE1EBBE@oma04cexch01.westdevinc.com> Message-ID: What command are you running when you get this? any stack trace? On Tue, Jul 7, 2015 at 9:27 PM, Gandikota, Murthy wrote: > Hi All > > > > Getting this error on Windows 7. The command runs fine on Linux > > > > CreateProcess error=206, The filename or extension is too long > > > > Please view this link for the full classpath given to java: > > > > > http://www.java-forums.org/apache-maven/87771-createprocess-error-206-filename-extension-too-long.html > > > > The above is a fairly old post (April, 2014). Things may have changed in > the mean time (the wheel of technology never stops, except for MSJ > > > > I?d grateful for any help. > > > > Best regards > > _______________________________________________ > 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/20150707/053295d6/attachment.html From jason.greene at redhat.com Tue Jul 7 17:19:52 2015 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 7 Jul 2015 16:19:52 -0500 Subject: [wildfly-dev] Including Keycloak client adapters in WildFly 10 In-Reply-To: <2083988224.31710463.1435923649086.JavaMail.zimbra@redhat.com> References: <2083988224.31710463.1435923649086.JavaMail.zimbra@redhat.com> Message-ID: <1A8F606B-E548-4FD3-979E-819686D84922@redhat.com> > On Jul 3, 2015, at 6:40 AM, Stian Thorgersen wrote: > > Keycloak provides an adapter, including a WildFly extensions, to make it easier to add authentication to JavaEE applications with Keycloak. Sorry for my delay replying. Comments are inline: > > It includes a few modules. Currently 8 Keycloak specific modules and one 1 third-party. The third-party is net.iharder.base64. We already have many Base64 implementations. It?s pretty easy to pull one in with cut and paste. Java 8 also provides one, so that could be used. > > As the WildFly extensions includes a deployment processor that configures the authentication method as well as dependencies for a deployment it's easy to add authentication to a JavaEE application. All you need to do is specify it in standalone.xml, for example: > > ... > 675356d8-2b6b-4602-a74f-7079e0555885 You probably already did this, but such an attribute should support vault usage as well so that credentials can be kept out of configs. > > ... > > I'd like to explore if we can add this extension and the required modules directly to WildFly 10, rather than require users to add it themselves. Can you sync up with the elytron team? They are making other changes in this area, which are not yet in 10, and I want to make sure thats all compatible. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From mgandikota at westechmed.com Tue Jul 7 19:56:44 2015 From: mgandikota at westechmed.com (Gandikota, Murthy) Date: Tue, 7 Jul 2015 23:56:44 +0000 Subject: [wildfly-dev] CreateProcess error=206, The filename or extension is too long In-Reply-To: References: <300155EADBAD7948B33FE136A4BF600D4EE1EBBE@oma04cexch01.westdevinc.com> Message-ID: <300155EADBAD7948B33FE136A4BF600D4EE1ED59@oma04cexch01.westdevinc.com> >What command are you running when you get this? >any stack trace? An engineer in my org has encountered while running a java process with a very long classpath on Windows 7. As Eduardo has indicated, there are a few options: eg. Pathing jar. Apparently there is no easy fix. If you could kindly provide one, I?d be grateful. Here is the specific error we are seeing: [ERROR] Failed to execute goal org.apache.cxf:cxf-java2ws-plugin:3.0.4:java2ws (process-classes-ivr) on project xyz: Error while executing process. Cannot run program "C:\Program Files\Java\jdk1.8.0_40\jre\bin\java.exe" (i n directory "C:\dev\mycom\code\xyz\target"): CreateProcess error=206, The filename or extension is too long -> [Help 1] Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150707/6f6ba9c1/attachment.html From jperkins at redhat.com Wed Jul 8 19:36:05 2015 From: jperkins at redhat.com (James R. Perkins) Date: Wed, 8 Jul 2015 16:36:05 -0700 Subject: [wildfly-dev] Batch Subsystem Changes In-Reply-To: <559AD34A.5030307@redhat.com> References: <559AD34A.5030307@redhat.com> Message-ID: <559DB3E5.5020004@redhat.com> I've got the initial work done for this now [1] (only the last commit). It still needs to be determined how a legacy configuration with a JDBC job repository will work. The legacy configuration used a JNDI name which won't work with the data source capabilities. If anyone has ideas here that would be helpful. I didn't do any work to support both subsystems running side-by-side. If that's something that should be done I think it would be fairly easy to do. [1]: https://github.com/wildfly/wildfly/compare/master...jamezp:WFLY-4811 On 07/06/2015 12:13 PM, James R. Perkins wrote: > Hello All, > The past couple weeks I've been working on basically a redo of the > batch subsystem. Almost the entire management model is changing to > hopefully make it more user friendly. > > In WildFly 8 and WildFly 9 the model looked like the following: > > { > "job-repository-type" => "in-memory", > "job-repository" => {"jdbc" => {"jndi-name" => undefined}}, > "thread-factory" => undefined, > "thread-pool" => {"batch" => { > "keepalive-time" => { > "time" => 30L, > "unit" => "SECONDS" > }, > "max-threads" => 10, > "name" => "batch", > "thread-factory" => undefined > }} > } > > The job-repository-type could either be jdcb or in-memory. The > jndi-name attribute on the single job-repository=jdbc resource could > be undefined indicating the default data-source should be used or JNDI > name to look up the data-source with no validation being done until > the user actually tries to deploy a batch deployment. > > The thread-pool and thread-factory are the same as other resources > that use the thread "subsystem" shared resources. > > As you can see it's not very intuitive and somewhat clumsy to say the > least. Only a single job-repository could be defined which isn't great > for multiple deployments. > > In WildFly 10 the model, at least currently, will look like: > > { > "default-job-repository" => "default", > "in-memory-job-repository" => {"default" => {}}, > "jdbc-job-repository" => {"jdbc" => {"data-source" => "ExampleDS"}}, > "thread-factory" => undefined, > "thread-pool" => {"batch" => { > "active-count" => 0, > "completed-task-count" => 0L, > "current-thread-count" => 0, > "keepalive-time" => { > "time" => 30L, > "unit" => "SECONDS" > }, > "largest-thread-count" => 0, > "max-threads" => 10, > "name" => "batch", > "queue-size" => 0, > "rejected-count" => 0, > "task-count" => 0L, > "thread-factory" => undefined > }} > } > > The default-job-repository will be an attribute similar to the > previous job-repository attribute. The difference being you can use > any named in-memory-job-repository or jdbc-job-repository. You can > have any number of in-memory or JDBC job repositories. > > The data-source attribute value on a jdbc-job-repository resource will > use the org.wildfly.data-source [1]. The name of the data-source is > used instead of the JNDI which is a much cleaner approach. > > The thread-factory may be removed and the thread-pool may be changed > to use attribute groups (once I figure out how to use them :)). > > As part of this I considered changing the name from batch to > batch-jberet. The main concern I had with this was the web console, > but I seem to have broken that anyway with the changes to the model. > Does anyone have opinions on a name change to batch-jberet? > > Also parsing an old configuration may have some issues if the user was > using a JDBC job repository. I've currently not found a good way to > find a data-source resource name based on a JNDI name. I'm not sure if > we should just fail when adding a legacy JDBC job repository. Any > suggestions here would be helpful. > > Any comments or concerns in general are welcome. This is our chance to > get it right this time. > > > [1]: https://github.com/wildfly/wildfly/pull/7682 > -- James R. Perkins JBoss by Red Hat From tomaz.cerar at gmail.com Thu Jul 9 09:54:56 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 9 Jul 2015 15:54:56 +0200 Subject: [wildfly-dev] CreateProcess error=206, The filename or extension is too long In-Reply-To: <300155EADBAD7948B33FE136A4BF600D4EE1ED59@oma04cexch01.westdevinc.com> References: <300155EADBAD7948B33FE136A4BF600D4EE1EBBE@oma04cexch01.westdevinc.com> <300155EADBAD7948B33FE136A4BF600D4EE1ED59@oma04cexch01.westdevinc.com> Message-ID: Hey, given the error you posted, problem is in apache cxf plugin. This can be fixed in plugin itself, it should be using ProcessBuilder api instead of just executing command line. I would suggest you report bug / post on their mailing list. As workaround I would suggest you move JDK somewhere nearer root of drive, something like c:\tools\jdk_1.8.0\ would probably make it work. -- tomaz On Wed, Jul 8, 2015 at 1:56 AM, Gandikota, Murthy wrote: > >What command are you running when you get this? > > >any stack trace? > > > > An engineer in my org has encountered while running a java process with a > very long classpath on Windows 7. As Eduardo has indicated, there are a few > options: eg. Pathing jar. Apparently there is no easy fix. If you could > kindly provide one, I?d be grateful. > > > > Here is the specific error we are seeing: > > > > [ERROR] Failed to execute goal > org.apache.cxf:cxf-java2ws-plugin:3.0.4:java2ws (process-classes-ivr) on > project xyz: Error while executing process. Cannot run program "C:\Program > Files\Java\jdk1.8.0_40\jre\bin\java.exe" (i > n directory "C:\dev\mycom\code\xyz\target"): CreateProcess error=206, The > filename or extension is too long -> [Help 1] > > > > Regards > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150709/ba9f8973/attachment.html From mstrukel at redhat.com Thu Jul 9 09:57:31 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 9 Jul 2015 09:57:31 -0400 (EDT) Subject: [wildfly-dev] Using feature packs for custom distributions In-Reply-To: <858942467.16646940.1436450079823.JavaMail.zimbra@redhat.com> Message-ID: <1078508222.16648070.1436450251162.JavaMail.zimbra@redhat.com> For Keycloak we?ve been trying to create a trimmed down distribution of Keycloak server, basing it on servlet-feature-pack rather than full-feature-pack, since we don?t need many of the subsystems. We?ve encountered some issues though that made us step back and stick to using full-feature-pack as a basis for Keycloak server distribution. If we find a way to address these issues in the future we?ll reconsider, but for now we don?t see much sense in basing our Keycloak distribution on servlet-feature-pack. There are two big isues for us: 1) Big module dependency trees Our goal was to reduce the distribution size by reducing the number of subsystems, and modules shipped. We guessed that since we don?t use EJB, JMS, WS - but basically just JAX-RS and datasources, the resulting distribution based on servlet-feature-pack wouldn?t get a lot bigger than OOTB servlet-feature-pack. But it turns out that enabling virtually any additional subsystem - in our case we want to use datasources, which are provided by org.jboss.as.connector - that pulls in around 90Mb of non-optional dependencies. That?s a lot just to get datasources support. What?s interesting is that adding a different subsystem support e.g. org.jboss.as.jaxrs pulls in the same dependency tree - i.e. adding JAXRS support pulls in the same dependency tree as adding Datasources support - that?s how intertwined the dependencies currently are. Using servlet-feature-pack for distributions that require some additional subsystems from full-feature-set is thus not very effective to significantly reduce custom distribution?s disk footprint. There is a tool I wrote as part of my analysis that I used to analyze the size of dependency trees: https://github.com/mstruk/keycloak-moduletool 2) Staying in-sync with changes in full-feature-pack Creating a custom feature pack that is a subset of full-feature-pack requires copying module.xml files from wildfly/feature-pack source tree into custom feature pack source tree. Adding org.jboss.as.connector means copying over hundreds of modules (186 to be precise). As Wildfly development moves on, any changes to module.xml files have to be synced into the custom feature pack. That has the potential to be a huge maintenance burden, and a source of errors. One way to address this would be extended syntax somewhere in feature pack definition project to say something like: And that would replace copying over module directories, and module.xml files. And guarantee that things remain in-sync. For our use-case this would also be addressed by wildfly providing a feature-pack definition that?s somewhere between servlet-feature-pack and full-feature-pack - as long as it contains datasources support, and jaxrs support ... Another thing is provisioning of feature packs, which I address in another email. - marko From mstrukel at redhat.com Thu Jul 9 10:02:54 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 9 Jul 2015 10:02:54 -0400 (EDT) Subject: [wildfly-dev] Feature pack provisioning In-Reply-To: <1954322073.16648436.1436450303191.JavaMail.zimbra@redhat.com> Message-ID: <930099469.16650706.1436450574022.JavaMail.zimbra@redhat.com> Currently wildfly-server-provisioning-maven-plugin always generates a full Wildfly distribution. For Keycloak project we have three different cases of provisioning, and it would be great to be able to cover it with a common wildfly provided tool: 1) full server distribution 2) overlay distribution (unzip into existing OOTB Wildfly distribution - your problem if you use unsupported Wildfly version) 3) provision into existing Wildfly server detecting version mismatches, and configuring existing and additional subsystems for Keycloak to run properly. First one is what?s currently supported, and what we use. Second one is what we currently hack up by extracting modules directory from (1) - it would support this use case better if wildfly-server-provisioning-maven-plugin could generate 'modules only' for example. The third one requires a CLI installer tool. I?m not aware that currently there is something for that, and we are loath to develop one from scratch. Is it realistic to expect 2) and 3) in not so distant future? - marko From jason.greene at redhat.com Thu Jul 9 11:13:58 2015 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 9 Jul 2015 10:13:58 -0500 Subject: [wildfly-dev] Using feature packs for custom distributions In-Reply-To: <1078508222.16648070.1436450251162.JavaMail.zimbra@redhat.com> References: <1078508222.16648070.1436450251162.JavaMail.zimbra@redhat.com> Message-ID: > On Jul 9, 2015, at 8:57 AM, Marko Strukelj wrote: > > > For Keycloak we?ve been trying to create a trimmed down distribution of Keycloak server, basing it on servlet-feature-pack rather than full-feature-pack, since we don?t need many of the subsystems. We?ve encountered some issues though that made us step back and stick to using full-feature-pack as a basis for Keycloak server distribution. If we find a way to address these issues in the future we?ll reconsider, but for now we don?t see much sense in basing our Keycloak distribution on servlet-feature-pack. > > There are two big isues for us: > > 1) Big module dependency trees > > Our goal was to reduce the distribution size by reducing the number of subsystems, and modules shipped. We guessed that since we don?t use EJB, JMS, WS - but basically just JAX-RS and datasources, the resulting distribution based on servlet-feature-pack wouldn?t get a lot bigger than OOTB servlet-feature-pack. But it turns out that enabling virtually any additional subsystem - in our case we want to use datasources, which are provided by org.jboss.as.connector - that pulls in around 90Mb of non-optional dependencies. That?s a lot just to get datasources support. > > What?s interesting is that adding a different subsystem support e.g. org.jboss.as.jaxrs pulls in the same dependency tree - i.e. adding JAXRS support pulls in the same dependency tree as adding Datasources support - that?s how intertwined the dependencies currently are. > > Using servlet-feature-pack for distributions that require some additional subsystems from full-feature-set is thus not very effective to significantly reduce custom distribution?s disk footprint. > > There is a tool I wrote as part of my analysis that I used to analyze the size of dependency trees: https://github.com/mstruk/keycloak-moduletool Yes it sounds like some work needs to be done here to reduce the dependency chain in this area. Pulling in JCA will require transactions, and currently transactions pulls in weld and web services related items. The former is likely due to the new JTA bean support in EE7, but that should be optional for sure. > > 2) Staying in-sync with changes in full-feature-pack > > Creating a custom feature pack that is a subset of full-feature-pack requires copying module.xml files from wildfly/feature-pack source tree into custom feature pack source tree. Adding org.jboss.as.connector means copying over hundreds of modules (186 to be precise). As Wildfly development moves on, any changes to module.xml files have to be synced into the custom feature pack. That has the potential to be a huge maintenance burden, and a source of errors. One way to address this would be extended syntax somewhere in feature pack definition project to say something like: > > > > And that would replace copying over module directories, and module.xml files. And guarantee that things remain in-sync. > > For our use-case this would also be addressed by wildfly providing a feature-pack definition that?s somewhere between servlet-feature-pack and full-feature-pack - as long as it contains datasources support, and jaxrs support ? I think this is a good idea, to skip optional deps. > > Another thing is provisioning of feature packs, which I address in another email. > > > - marko > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jperkins at redhat.com Fri Jul 10 15:30:57 2015 From: jperkins at redhat.com (James R. Perkins) Date: Fri, 10 Jul 2015 12:30:57 -0700 Subject: [wildfly-dev] WildFly Core 2.0.0.Alpha8 Released Message-ID: <55A01D71.1040204@redhat.com> But wait a minute, what happened to Alpha7? Long story short, I messed it up :) -- James R. Perkins JBoss by Red Hat From frank.langelage at osnanet.de Sat Jul 11 06:23:19 2015 From: frank.langelage at osnanet.de (Frank Langelage) Date: Sat, 11 Jul 2015 12:23:19 +0200 Subject: [wildfly-dev] WildFly 10.0.0.Alpha5: NPE in org.hibernate.cache.internal.CacheDataDescriptionImpl.decode() ? Message-ID: <55A0EE97.3070708@osnanet.de> After upgrading WildFly to latest alpha5 including the Hibernate ORM update to 5.0.0.CR2 the persistence unit inside my ear cannot be started anymore. 11.07. 12:17:54,698 INFO [org.jboss.as.jpa#run] WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 'maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev' 11.07. 12:17:54,954 INFO [org.hibernate.jpa.internal.util.LogHelper#logPersistenceUnitInformation] HHH000204: Processing PersistenceUnitInfo [ name: maj2e-langfr-dev ...] 11.07. 12:17:55,546 INFO [org.hibernate.Version#logVersion] HHH000412: Hibernate Core {5.0.0.CR2} 11.07. 12:17:55,552 INFO [org.hibernate.cfg.Environment#] HHH000206: hibernate.properties not found 11.07. 12:17:55,562 INFO [org.hibernate.cfg.Environment#buildBytecodeProvider] HHH000021: Bytecode provider name : javassist 11.07. 12:17:55,701 INFO [org.hibernate.orm.deprecation#] HHH90000001: Found usage of deprecated setting for specifying Scanner [hibernate.ejb.resource_scanner]; use [hibernate.archive.scanner] instead 11.07. 12:17:55,761 INFO [org.hibernate.annotations.common.Version#] HCANN000001: Hibernate Commons Annotations {5.0.0.Final} 11.07. 12:17:55,877 INFO [org.jboss.weld.deployer#deploy] WFLYWELD0003: Processing weld deployment ejb-session-core.jar 11.07. 12:17:55,940 INFO [org.jboss.weld.deployer#deploy] WFLYWELD0006: Starting Services for CDI deployment: maj2e-langfr-dev.ear 11.07. 12:17:56,447 INFO [org.jboss.weld.Version#] WELD-000900: 2.3.0 (Beta2) 11.07. 12:18:14,049 INFO [org.jboss.weld.deployer#start] WFLYWELD0009: Starting weld service for deployment maj2e-langfr-dev.ear [GC (Allocation Failure) [PSYoungGen: 475136K->58002K(573440K)] 560180K->143054K(1974272K), 0.4947124 secs] [Times: user=0.80 sys=0.04, real=0.49 secs] 11.07. 12:18:18,028 INFO [org.jboss.as.jpa#run] WFLYJPA0010: Starting Persistence Unit (phase 2 of 2) Service 'maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev' 11.07. 12:18:19,201 INFO [org.hibernate.dialect.Dialect#] HHH000400: Using dialect: org.hibernate.dialect.Oracle10gDialect 11.07. 12:18:19,521 INFO [org.hibernate.envers.boot.internal.EnversServiceImpl#configure] Envers integration enabled? : true [GC (Allocation Failure) [PSYoungGen: 537234K->50463K(581632K)] 622286K->135516K(1982464K), 0.4342550 secs] [Times: user=0.80 sys=0.00, real=0.43 secs] 11.07. 12:18:36,361 ERROR [org.jboss.msc.service.fail#failed] MSC000001: Failed to start service jboss.persistenceunit."maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev": org.jboss.msc.service.StartException in service jboss.persistenceunit."maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev": javax.persistence.PersistenceException: [PersistenceUnit: maj2e-langfr-dev] Unable to build Hibernate SessionFactory at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172) at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:666) at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: javax.persistence.PersistenceException: [PersistenceUnit: maj2e-langfr-dev] Unable to build Hibernate SessionFactory at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:877) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:805) at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) ... 7 more Caused by: java.lang.NullPointerException at org.hibernate.cache.internal.CacheDataDescriptionImpl.decode(CacheDataDescriptionImpl.java:77) at org.hibernate.internal.SessionFactoryImpl.determineEntityRegionAccessStrategy(SessionFactoryImpl.java:628) at org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:330) at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444) at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802) ... 9 more My persistence.xml: java:jboss/datasources/@MBI_DBNAME@ ENABLE_SELECTIVE NONE From eduardo.santanadasilva at gmail.com Sat Jul 11 08:37:53 2015 From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva) Date: Sat, 11 Jul 2015 09:37:53 -0300 Subject: [wildfly-dev] WildFly 10.0.0.Alpha5: NPE in org.hibernate.cache.internal.CacheDataDescriptionImpl.decode() ? In-Reply-To: <55A0EE97.3070708@osnanet.de> References: <55A0EE97.3070708@osnanet.de> Message-ID: <289EA5E1-D09C-4061-BD4E-E10BEF661EF8@gmail.com> Maybe something related to your persistence provider. The error seems to be here: >>>EntityManagerFactoryBuilder emfBuilder = phaseOnePersistenceUnitService.getEntityManagerFa ctoryBuilder(); I'm not sure about the following, is just a hint... Could you try add this line? org.hibernate.ejb.HibernatePersistence Is the hibernate-entitymanager-.jar on your pom.xml? Are you using jboss-deployment-structures.xml file? Could you provide it? Eduardo Sant'Ana da Silva On Jul 11, 2015, at 7:23 AM, Frank Langelage wrote: > After upgrading WildFly to latest alpha5 including the Hibernate ORM > update to 5.0.0.CR2 the persistence unit inside my ear cannot be started > anymore. > > 11.07. 12:17:54,698 INFO [org.jboss.as.jpa#run] WFLYJPA0010: Starting > Persistence Unit (phase 1 of 2) Service > 'maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev' > 11.07. 12:17:54,954 INFO > [org.hibernate.jpa.internal.util.LogHelper#logPersistenceUnitInformation] HHH000204: > Processing PersistenceUnitInfo [ > name: maj2e-langfr-dev > ...] > 11.07. 12:17:55,546 INFO [org.hibernate.Version#logVersion] HHH000412: > Hibernate Core {5.0.0.CR2} > 11.07. 12:17:55,552 INFO [org.hibernate.cfg.Environment#] > HHH000206: hibernate.properties not found > 11.07. 12:17:55,562 INFO > [org.hibernate.cfg.Environment#buildBytecodeProvider] HHH000021: > Bytecode provider name : javassist > 11.07. 12:17:55,701 INFO [org.hibernate.orm.deprecation#] > HHH90000001: Found usage of deprecated setting for specifying Scanner > [hibernate.ejb.resource_scanner]; use [hibernate.archive.scanner] instead > 11.07. 12:17:55,761 INFO > [org.hibernate.annotations.common.Version#] HCANN000001: > Hibernate Commons Annotations {5.0.0.Final} > 11.07. 12:17:55,877 INFO [org.jboss.weld.deployer#deploy] WFLYWELD0003: > Processing weld deployment ejb-session-core.jar > 11.07. 12:17:55,940 INFO [org.jboss.weld.deployer#deploy] WFLYWELD0006: > Starting Services for CDI deployment: maj2e-langfr-dev.ear > 11.07. 12:17:56,447 INFO [org.jboss.weld.Version#] WELD-000900: > 2.3.0 (Beta2) > 11.07. 12:18:14,049 INFO [org.jboss.weld.deployer#start] WFLYWELD0009: > Starting weld service for deployment maj2e-langfr-dev.ear > [GC (Allocation Failure) [PSYoungGen: 475136K->58002K(573440K)] > 560180K->143054K(1974272K), 0.4947124 secs] [Times: user=0.80 sys=0.04, > real=0.49 secs] > 11.07. 12:18:18,028 INFO [org.jboss.as.jpa#run] WFLYJPA0010: Starting > Persistence Unit (phase 2 of 2) Service > 'maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev' > 11.07. 12:18:19,201 INFO [org.hibernate.dialect.Dialect#] > HHH000400: Using dialect: org.hibernate.dialect.Oracle10gDialect > 11.07. 12:18:19,521 INFO > [org.hibernate.envers.boot.internal.EnversServiceImpl#configure] Envers > integration enabled? : true > [GC (Allocation Failure) [PSYoungGen: 537234K->50463K(581632K)] > 622286K->135516K(1982464K), 0.4342550 secs] [Times: user=0.80 sys=0.00, > real=0.43 secs] > 11.07. 12:18:36,361 ERROR [org.jboss.msc.service.fail#failed] MSC000001: > Failed to start service > jboss.persistenceunit."maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev": > org.jboss.msc.service.StartException in service > jboss.persistenceunit."maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev": > javax.persistence.PersistenceException: [PersistenceUnit: > maj2e-langfr-dev] Unable to build Hibernate SessionFactory > at > org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172) > at > org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) > at > org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:666) > at > org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: javax.persistence.PersistenceException: [PersistenceUnit: > maj2e-langfr-dev] Unable to build Hibernate SessionFactory > at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:877) > at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:805) > at > org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) > at > org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) > ... 7 more > Caused by: java.lang.NullPointerException > at > org.hibernate.cache.internal.CacheDataDescriptionImpl.decode(CacheDataDescriptionImpl.java:77) > at > org.hibernate.internal.SessionFactoryImpl.determineEntityRegionAccessStrategy(SessionFactoryImpl.java:628) > at > org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:330) > at > org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444) > at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802) > ... 9 more > > My persistence.xml: > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence > http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd" version="2.1"> > > java:jboss/datasources/@MBI_DBNAME@ > ENABLE_SELECTIVE > NONE > > value="org.hibernate.dialect. at HIBERNATE_DIALECT@"/> > > > > value="@SHOW_SQL@"/> > > > > > _______________________________________________ > 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/20150711/19730bd3/attachment-0001.html From frank.langelage at osnanet.de Sat Jul 11 09:18:18 2015 From: frank.langelage at osnanet.de (Frank Langelage) Date: Sat, 11 Jul 2015 15:18:18 +0200 Subject: [wildfly-dev] WildFly 10.0.0.Alpha5: NPE in org.hibernate.cache.internal.CacheDataDescriptionImpl.decode() ? In-Reply-To: <289EA5E1-D09C-4061-BD4E-E10BEF661EF8@gmail.com> References: <55A0EE97.3070708@osnanet.de> <289EA5E1-D09C-4061-BD4E-E10BEF661EF8@gmail.com> Message-ID: <55A1179A.4080300@osnanet.de> Setting the provider element to the value you suggested makes it even worse: Caused by: javax.persistence.PersistenceException: WFLYJPA0057: PersistenceProvider 'org.hibernate.ejb.HibernatePersistence' not found at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:1006) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.nextPhaseDependsOnPersistenceUnit(PersistenceUnitServiceHandler.java:1045) at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:135) at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) ... 5 more I added instead this org.hibernate.jpa.HibernatePersistenceProvider but this doe not change anything. Same NPE as I had before. No, I do not have hibernate jar in my pom.xml, I not aven have a pom.xml file because I'm using ant for build. ;-) I do not provide my own hibernate version, I just try the use the version 5.0.0.CR2 delivered by WildFly now. With the hibernate version 4.3.10 used until the day before yesterday everything was fine. So it's something related to the hibernate update. Either it's not yet complete, but how did the testsuite run successful then, or a change to persistence.xml or else is needed. On 11.07.15 14:37, Eduardo Sant'Ana da Silva wrote: > Maybe something related to your persistence provider. > > The error seems to be here: > >>>EntityManagerFactoryBuilder emfBuilder = > phaseOnePersistenceUnitService.getEntityManagerFactoryBuilder(); > > I'm not sure about the following, is just a hint... > Could you try add this line? > org.hibernate.ejb.HibernatePersistence > Is the hibernate-entitymanager-.jar on your pom.xml? > Are you using jboss-deployment-structures.xml file? Could you provide it? > > > Eduardo Sant'Ana da Silva > > On Jul 11, 2015, at 7:23 AM, Frank Langelage > > wrote: > >> After upgrading WildFly to latest alpha5 including the Hibernate ORM >> update to 5.0.0.CR2 the persistence unit inside my ear cannot be started >> anymore. >> >> 11.07. 12:17:54,698 INFO [org.jboss.as.jpa#run] WFLYJPA0010: Starting >> Persistence Unit (phase 1 of 2) Service >> 'maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev' >> 11.07. 12:17:54,954 INFO >> [org.hibernate.jpa.internal.util.LogHelper#logPersistenceUnitInformation] >> HHH000204: >> Processing PersistenceUnitInfo [ >> name: maj2e-langfr-dev >> ...] >> 11.07. 12:17:55,546 INFO [org.hibernate.Version#logVersion] HHH000412: >> Hibernate Core {5.0.0.CR2} >> 11.07. 12:17:55,552 INFO [org.hibernate.cfg.Environment#] >> HHH000206: hibernate.properties not found >> 11.07. 12:17:55,562 INFO >> [org.hibernate.cfg.Environment#buildBytecodeProvider] HHH000021: >> Bytecode provider name : javassist >> 11.07. 12:17:55,701 INFO [org.hibernate.orm.deprecation#] >> HHH90000001: Found usage of deprecated setting for specifying Scanner >> [hibernate.ejb.resource_scanner]; use [hibernate.archive.scanner] instead >> 11.07. 12:17:55,761 INFO >> [org.hibernate.annotations.common.Version#] HCANN000001: >> Hibernate Commons Annotations {5.0.0.Final} >> 11.07. 12:17:55,877 INFO [org.jboss.weld.deployer#deploy] WFLYWELD0003: >> Processing weld deployment ejb-session-core.jar >> 11.07. 12:17:55,940 INFO [org.jboss.weld.deployer#deploy] WFLYWELD0006: >> Starting Services for CDI deployment: maj2e-langfr-dev.ear >> 11.07. 12:17:56,447 INFO [org.jboss.weld.Version#] WELD-000900: >> 2.3.0 (Beta2) >> 11.07. 12:18:14,049 INFO [org.jboss.weld.deployer#start] WFLYWELD0009: >> Starting weld service for deployment maj2e-langfr-dev.ear >> [GC (Allocation Failure) [PSYoungGen: 475136K->58002K(573440K)] >> 560180K->143054K(1974272K), 0.4947124 secs] [Times: user=0.80 sys=0.04, >> real=0.49 secs] >> 11.07. 12:18:18,028 INFO [org.jboss.as.jpa#run] WFLYJPA0010: Starting >> Persistence Unit (phase 2 of 2) Service >> 'maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev' >> 11.07. 12:18:19,201 INFO [org.hibernate.dialect.Dialect#] >> HHH000400: Using dialect: org.hibernate.dialect.Oracle10gDialect >> 11.07. 12:18:19,521 INFO >> [org.hibernate.envers.boot.internal.EnversServiceImpl#configure] Envers >> integration enabled? : true >> [GC (Allocation Failure) [PSYoungGen: 537234K->50463K(581632K)] >> 622286K->135516K(1982464K), 0.4342550 secs] [Times: user=0.80 sys=0.00, >> real=0.43 secs] >> 11.07. 12:18:36,361 ERROR [org.jboss.msc.service.fail#failed] MSC000001: >> Failed to start service >> jboss.persistenceunit."maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev": >> >> org.jboss.msc.service.StartException in service >> jboss.persistenceunit."maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev": >> >> javax.persistence.PersistenceException: [PersistenceUnit: >> maj2e-langfr-dev] Unable to build Hibernate SessionFactory >> at >> org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172) >> at >> org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) >> at >> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:666) >> at >> org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: >> maj2e-langfr-dev] Unable to build Hibernate SessionFactory >> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:877) >> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:805) >> at >> org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) >> at >> org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) >> ... 7 more >> Caused by: java.lang.NullPointerException >> at >> org.hibernate.cache.internal.CacheDataDescriptionImpl.decode(CacheDataDescriptionImpl.java:77) >> at >> org.hibernate.internal.SessionFactoryImpl.determineEntityRegionAccessStrategy(SessionFactoryImpl.java:628) >> at >> org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:330) >> at >> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444) >> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802) >> ... 9 more >> >> My persistence.xml: >> >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence >> http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd" >> version="2.1"> >> >> java:jboss/datasources/@MBI_DBNAME@ >> ENABLE_SELECTIVE >> NONE >> >> > value="org.hibernate.dialect. at HIBERNATE_DIALECT@"/> >> >> >> >> > value="@SHOW_SQL@"/> >> >> >> >> >> _______________________________________________ >> 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/20150711/04e1bb5c/attachment.html From jai.forums2013 at gmail.com Sat Jul 11 09:55:08 2015 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 11 Jul 2015 19:25:08 +0530 Subject: [wildfly-dev] WildFly 10.0.0.Alpha5: NPE in org.hibernate.cache.internal.CacheDataDescriptionImpl.decode() ? In-Reply-To: <55A0EE97.3070708@osnanet.de> References: <55A0EE97.3070708@osnanet.de> Message-ID: <55A1203C.7030109@gmail.com> Looking at the code which is generating the NPE, it looks like some persistent entity within your deployment is missing an identifier. Enable TRACE level logging of org.hibernate package and see which persistent entity is being processed when this happens. Of course, a better error message needs to be logged if at all this is a user/deployment error. So you might want to file a JIRA in Hibernate project. -Jaikiran On Saturday 11 July 2015 03:53 PM, Frank Langelage wrote: > After upgrading WildFly to latest alpha5 including the Hibernate ORM > update to 5.0.0.CR2 the persistence unit inside my ear cannot be started > anymore. > > 11.07. 12:17:54,698 INFO [org.jboss.as.jpa#run] WFLYJPA0010: Starting > Persistence Unit (phase 1 of 2) Service > 'maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev' > 11.07. 12:17:54,954 INFO > [org.hibernate.jpa.internal.util.LogHelper#logPersistenceUnitInformation] HHH000204: > Processing PersistenceUnitInfo [ > name: maj2e-langfr-dev > ...] > 11.07. 12:17:55,546 INFO [org.hibernate.Version#logVersion] HHH000412: > Hibernate Core {5.0.0.CR2} > 11.07. 12:17:55,552 INFO [org.hibernate.cfg.Environment#] > HHH000206: hibernate.properties not found > 11.07. 12:17:55,562 INFO > [org.hibernate.cfg.Environment#buildBytecodeProvider] HHH000021: > Bytecode provider name : javassist > 11.07. 12:17:55,701 INFO [org.hibernate.orm.deprecation#] > HHH90000001: Found usage of deprecated setting for specifying Scanner > [hibernate.ejb.resource_scanner]; use [hibernate.archive.scanner] instead > 11.07. 12:17:55,761 INFO > [org.hibernate.annotations.common.Version#] HCANN000001: > Hibernate Commons Annotations {5.0.0.Final} > 11.07. 12:17:55,877 INFO [org.jboss.weld.deployer#deploy] WFLYWELD0003: > Processing weld deployment ejb-session-core.jar > 11.07. 12:17:55,940 INFO [org.jboss.weld.deployer#deploy] WFLYWELD0006: > Starting Services for CDI deployment: maj2e-langfr-dev.ear > 11.07. 12:17:56,447 INFO [org.jboss.weld.Version#] WELD-000900: > 2.3.0 (Beta2) > 11.07. 12:18:14,049 INFO [org.jboss.weld.deployer#start] WFLYWELD0009: > Starting weld service for deployment maj2e-langfr-dev.ear > [GC (Allocation Failure) [PSYoungGen: 475136K->58002K(573440K)] > 560180K->143054K(1974272K), 0.4947124 secs] [Times: user=0.80 sys=0.04, > real=0.49 secs] > 11.07. 12:18:18,028 INFO [org.jboss.as.jpa#run] WFLYJPA0010: Starting > Persistence Unit (phase 2 of 2) Service > 'maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev' > 11.07. 12:18:19,201 INFO [org.hibernate.dialect.Dialect#] > HHH000400: Using dialect: org.hibernate.dialect.Oracle10gDialect > 11.07. 12:18:19,521 INFO > [org.hibernate.envers.boot.internal.EnversServiceImpl#configure] Envers > integration enabled? : true > [GC (Allocation Failure) [PSYoungGen: 537234K->50463K(581632K)] > 622286K->135516K(1982464K), 0.4342550 secs] [Times: user=0.80 sys=0.00, > real=0.43 secs] > 11.07. 12:18:36,361 ERROR [org.jboss.msc.service.fail#failed] MSC000001: > Failed to start service > jboss.persistenceunit."maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev": > org.jboss.msc.service.StartException in service > jboss.persistenceunit."maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev": > javax.persistence.PersistenceException: [PersistenceUnit: > maj2e-langfr-dev] Unable to build Hibernate SessionFactory > at > org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172) > at > org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) > at > org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:666) > at > org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: javax.persistence.PersistenceException: [PersistenceUnit: > maj2e-langfr-dev] Unable to build Hibernate SessionFactory > at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:877) > at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:805) > at > org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) > at > org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) > ... 7 more > Caused by: java.lang.NullPointerException > at > org.hibernate.cache.internal.CacheDataDescriptionImpl.decode(CacheDataDescriptionImpl.java:77) > at > org.hibernate.internal.SessionFactoryImpl.determineEntityRegionAccessStrategy(SessionFactoryImpl.java:628) > at > org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:330) > at > org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444) > at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802) > ... 9 more > > My persistence.xml: > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence > http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd" version="2.1"> > > java:jboss/datasources/@MBI_DBNAME@ > ENABLE_SELECTIVE > NONE > > value="org.hibernate.dialect. at HIBERNATE_DIALECT@"/> > > > > value="@SHOW_SQL@"/> > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From smarlow at redhat.com Sat Jul 11 13:54:43 2015 From: smarlow at redhat.com (Scott Marlow) Date: Sat, 11 Jul 2015 13:54:43 -0400 Subject: [wildfly-dev] WildFly 10.0.0.Alpha5: NPE in org.hibernate.cache.internal.CacheDataDescriptionImpl.decode() ? In-Reply-To: <55A0EE97.3070708@osnanet.de> References: <55A0EE97.3070708@osnanet.de> Message-ID: <55A15863.4010609@redhat.com> Frank, I haven't seen this NPE yet. We just added the Hibernate ORM upgrade yesterday, thanks for the quick feedback! If you like, you could also mention this NPE issue on hibernate-dev at lists.jboss.org. A Hibernate Jira is also welcome if you can narrow down the likely cause. Have you tried setting shared-cache-mode to none? Scott shared-cache-mode>ENABLE_SELECTIVE On 07/11/2015 06:23 AM, Frank Langelage wrote: > After upgrading WildFly to latest alpha5 including the Hibernate ORM > update to 5.0.0.CR2 the persistence unit inside my ear cannot be started > anymore. > > 11.07. 12:17:54,698 INFO [org.jboss.as.jpa#run] WFLYJPA0010: Starting > Persistence Unit (phase 1 of 2) Service > 'maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev' > 11.07. 12:17:54,954 INFO > [org.hibernate.jpa.internal.util.LogHelper#logPersistenceUnitInformation] HHH000204: > Processing PersistenceUnitInfo [ > name: maj2e-langfr-dev > ...] > 11.07. 12:17:55,546 INFO [org.hibernate.Version#logVersion] HHH000412: > Hibernate Core {5.0.0.CR2} > 11.07. 12:17:55,552 INFO [org.hibernate.cfg.Environment#] > HHH000206: hibernate.properties not found > 11.07. 12:17:55,562 INFO > [org.hibernate.cfg.Environment#buildBytecodeProvider] HHH000021: > Bytecode provider name : javassist > 11.07. 12:17:55,701 INFO [org.hibernate.orm.deprecation#] > HHH90000001: Found usage of deprecated setting for specifying Scanner > [hibernate.ejb.resource_scanner]; use [hibernate.archive.scanner] instead > 11.07. 12:17:55,761 INFO > [org.hibernate.annotations.common.Version#] HCANN000001: > Hibernate Commons Annotations {5.0.0.Final} > 11.07. 12:17:55,877 INFO [org.jboss.weld.deployer#deploy] WFLYWELD0003: > Processing weld deployment ejb-session-core.jar > 11.07. 12:17:55,940 INFO [org.jboss.weld.deployer#deploy] WFLYWELD0006: > Starting Services for CDI deployment: maj2e-langfr-dev.ear > 11.07. 12:17:56,447 INFO [org.jboss.weld.Version#] WELD-000900: > 2.3.0 (Beta2) > 11.07. 12:18:14,049 INFO [org.jboss.weld.deployer#start] WFLYWELD0009: > Starting weld service for deployment maj2e-langfr-dev.ear > [GC (Allocation Failure) [PSYoungGen: 475136K->58002K(573440K)] > 560180K->143054K(1974272K), 0.4947124 secs] [Times: user=0.80 sys=0.04, > real=0.49 secs] > 11.07. 12:18:18,028 INFO [org.jboss.as.jpa#run] WFLYJPA0010: Starting > Persistence Unit (phase 2 of 2) Service > 'maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev' > 11.07. 12:18:19,201 INFO [org.hibernate.dialect.Dialect#] > HHH000400: Using dialect: org.hibernate.dialect.Oracle10gDialect > 11.07. 12:18:19,521 INFO > [org.hibernate.envers.boot.internal.EnversServiceImpl#configure] Envers > integration enabled? : true > [GC (Allocation Failure) [PSYoungGen: 537234K->50463K(581632K)] > 622286K->135516K(1982464K), 0.4342550 secs] [Times: user=0.80 sys=0.00, > real=0.43 secs] > 11.07. 12:18:36,361 ERROR [org.jboss.msc.service.fail#failed] MSC000001: > Failed to start service > jboss.persistenceunit."maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev": > org.jboss.msc.service.StartException in service > jboss.persistenceunit."maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev": > javax.persistence.PersistenceException: [PersistenceUnit: > maj2e-langfr-dev] Unable to build Hibernate SessionFactory > at > org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172) > at > org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) > at > org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:666) > at > org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: javax.persistence.PersistenceException: [PersistenceUnit: > maj2e-langfr-dev] Unable to build Hibernate SessionFactory > at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:877) > at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:805) > at > org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) > at > org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) > ... 7 more > Caused by: java.lang.NullPointerException > at > org.hibernate.cache.internal.CacheDataDescriptionImpl.decode(CacheDataDescriptionImpl.java:77) > at > org.hibernate.internal.SessionFactoryImpl.determineEntityRegionAccessStrategy(SessionFactoryImpl.java:628) > at > org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:330) > at > org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444) > at > org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802) > ... 9 more > > My persistence.xml: > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence > http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd" version="2.1"> > > java:jboss/datasources/@MBI_DBNAME@ > ENABLE_SELECTIVE > NONE > > value="org.hibernate.dialect. at HIBERNATE_DIALECT@"/> > > > > value="@SHOW_SQL@"/> > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From frank.langelage at osnanet.de Sun Jul 12 05:24:09 2015 From: frank.langelage at osnanet.de (Frank Langelage) Date: Sun, 12 Jul 2015 11:24:09 +0200 Subject: [wildfly-dev] WildFly 10.0.0.Alpha5: NPE in org.hibernate.cache.internal.CacheDataDescriptionImpl.decode() ? In-Reply-To: <55A15863.4010609@redhat.com> References: <55A0EE97.3070708@osnanet.de> <55A15863.4010609@redhat.com> Message-ID: <55A23239.7040103@osnanet.de> Disabling the caching in persistence.xml makes the problem disappear. Further investigations, enabling TRACE level logging on org.hibernate showed, that already the first cachable entity raises this problem. At the end, the cacheable entity classes which have a composite primary key are the problem. Cacheable entities with a single id field do not raise this exception. As already said, it worked fine with ORM 4.3.10 before so it seeems clear to me, that this is a hibernate bug. I'll create a Jira for it and see what happens. On 11.07.15 19:54, Scott Marlow wrote: > Frank, > > I haven't seen this NPE yet. We just added the Hibernate ORM upgrade > yesterday, thanks for the quick feedback! If you like, you could also > mention this NPE issue on hibernate-dev at lists.jboss.org. A Hibernate > Jira is also welcome if you can narrow down the likely cause. > > Have you tried setting shared-cache-mode to none? > > Scott > > shared-cache-mode>ENABLE_SELECTIVE > On 07/11/2015 06:23 AM, Frank Langelage wrote: >> After upgrading WildFly to latest alpha5 including the Hibernate ORM >> update to 5.0.0.CR2 the persistence unit inside my ear cannot be started >> anymore. >> >> 11.07. 12:17:54,698 INFO [org.jboss.as.jpa#run] WFLYJPA0010: Starting >> Persistence Unit (phase 1 of 2) Service >> 'maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev' >> 11.07. 12:17:54,954 INFO >> [org.hibernate.jpa.internal.util.LogHelper#logPersistenceUnitInformation] >> HHH000204: >> Processing PersistenceUnitInfo [ >> name: maj2e-langfr-dev >> ...] >> 11.07. 12:17:55,546 INFO [org.hibernate.Version#logVersion] HHH000412: >> Hibernate Core {5.0.0.CR2} >> 11.07. 12:17:55,552 INFO [org.hibernate.cfg.Environment#] >> HHH000206: hibernate.properties not found >> 11.07. 12:17:55,562 INFO >> [org.hibernate.cfg.Environment#buildBytecodeProvider] HHH000021: >> Bytecode provider name : javassist >> 11.07. 12:17:55,701 INFO [org.hibernate.orm.deprecation#] >> HHH90000001: Found usage of deprecated setting for specifying Scanner >> [hibernate.ejb.resource_scanner]; use [hibernate.archive.scanner] >> instead >> 11.07. 12:17:55,761 INFO >> [org.hibernate.annotations.common.Version#] HCANN000001: >> Hibernate Commons Annotations {5.0.0.Final} >> 11.07. 12:17:55,877 INFO [org.jboss.weld.deployer#deploy] WFLYWELD0003: >> Processing weld deployment ejb-session-core.jar >> 11.07. 12:17:55,940 INFO [org.jboss.weld.deployer#deploy] WFLYWELD0006: >> Starting Services for CDI deployment: maj2e-langfr-dev.ear >> 11.07. 12:17:56,447 INFO [org.jboss.weld.Version#] WELD-000900: >> 2.3.0 (Beta2) >> 11.07. 12:18:14,049 INFO [org.jboss.weld.deployer#start] WFLYWELD0009: >> Starting weld service for deployment maj2e-langfr-dev.ear >> [GC (Allocation Failure) [PSYoungGen: 475136K->58002K(573440K)] >> 560180K->143054K(1974272K), 0.4947124 secs] [Times: user=0.80 sys=0.04, >> real=0.49 secs] >> 11.07. 12:18:18,028 INFO [org.jboss.as.jpa#run] WFLYJPA0010: Starting >> Persistence Unit (phase 2 of 2) Service >> 'maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev' >> 11.07. 12:18:19,201 INFO [org.hibernate.dialect.Dialect#] >> HHH000400: Using dialect: org.hibernate.dialect.Oracle10gDialect >> 11.07. 12:18:19,521 INFO >> [org.hibernate.envers.boot.internal.EnversServiceImpl#configure] Envers >> integration enabled? : true >> [GC (Allocation Failure) [PSYoungGen: 537234K->50463K(581632K)] >> 622286K->135516K(1982464K), 0.4342550 secs] [Times: user=0.80 sys=0.00, >> real=0.43 secs] >> 11.07. 12:18:36,361 ERROR [org.jboss.msc.service.fail#failed] MSC000001: >> Failed to start service >> jboss.persistenceunit."maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev": >> >> org.jboss.msc.service.StartException in service >> jboss.persistenceunit."maj2e-langfr-dev.ear/ejb-entity.jar#maj2e-langfr-dev": >> >> javax.persistence.PersistenceException: [PersistenceUnit: >> maj2e-langfr-dev] Unable to build Hibernate SessionFactory >> at >> org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172) >> >> at >> org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) >> >> at >> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:666) >> >> at >> org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182) >> >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> at java.lang.Thread.run(Thread.java:745) >> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >> Caused by: javax.persistence.PersistenceException: [PersistenceUnit: >> maj2e-langfr-dev] Unable to build Hibernate SessionFactory >> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:877) >> >> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:805) >> >> at >> org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) >> >> at >> org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154) >> >> ... 7 more >> Caused by: java.lang.NullPointerException >> at >> org.hibernate.cache.internal.CacheDataDescriptionImpl.decode(CacheDataDescriptionImpl.java:77) >> >> at >> org.hibernate.internal.SessionFactoryImpl.determineEntityRegionAccessStrategy(SessionFactoryImpl.java:628) >> >> at >> org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:330) >> >> at >> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:444) >> >> at >> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802) >> >> ... 9 more >> >> My persistence.xml: >> >> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence >> http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd" >> version="2.1"> >> >> java:jboss/datasources/@MBI_DBNAME@ >> ENABLE_SELECTIVE >> NONE >> >> > value="org.hibernate.dialect. at HIBERNATE_DIALECT@"/> >> >> >> >> > value="@SHOW_SQL@"/> >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > From jason.greene at redhat.com Sun Jul 12 23:05:59 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Sun, 12 Jul 2015 23:05:59 -0400 (EDT) Subject: [wildfly-dev] 10.0.0.Alpha5 and Core 2.0.0.Alpha9 released Message-ID: The latest update in our biweekly Alpha series was tagged & released to maven last night. You can download it here: http://search.maven.org/remotecontent?filepath=org/wildfly/wildfly-dist/10.0.0.Alpha5/wildfly-dist-10.0.0.Alpha5.zip This release includes a major update to Hibernate 5, which is close to Final, so be sure to report any issues you run into it. Thanks! -Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150712/d63aa7a7/attachment.html From chaowan at redhat.com Mon Jul 13 01:54:35 2015 From: chaowan at redhat.com (Chao Wang) Date: Mon, 13 Jul 2015 13:54:35 +0800 Subject: [wildfly-dev] Wildfly start-up as service script depends on console log to determinate start result In-Reply-To: <5576F142.3030307@redhat.com> References: <5576F142.3030307@redhat.com> Message-ID: <55A3529B.4020706@redhat.com> On 06/09/2015 09:59 PM, Chao Wang wrote: > Hi all, > > The Wildfly start-up as service scripts wildfly-init-redhat.sh and > wildfly-init-debian.sh currently depend on a grep action of key > message 'WFLYSRV0025:' in console log to determinate whether service > start is successful. The log message indication is accurate, however, > it's not that robust since user can always remove console handler from > logging subsystem. I have opened a WFCORE enhancement jira > https://issues.jboss.org/browse/WFCORE-747 for it. > > For the moment, I have tried three options, they're all not that > perfect to implement > > 1. Stay with exact log message, users need to define their jboss log > directory such as $JBOSS_HOME/standalone/log/server.log for standalone > and $JBOSS_HOME/domain/log/host-controller.log for domain instead of > searching in console log. This is more like another workaround since > it is also volatile once we update log message in future release.(EAP > has 'JBAS015874:') > > 2. Use service pid, this is not precise because a long start-up can > crash in the last second. It needs to wait a suitable seconds before > checking pid existence. and still it can not avoid fake success in > rare case just before timeout. > > 3. Use read-attribute server-state through CLI connection as I did in > Pull Request on Jira. This is declined as it is possible that > authentication is required before connection. In such case, any non > encrypted password is not advised in configuration files. I have opened a PR to change the log key message dependency in start script https://github.com/wildfly/wildfly-core/pull/859 A jboss start marker file in temporary directory can be added to record launch result and its timestamp when it starts. wildfly-init-redhat.sh / wildfly-init-debian.sh will exam its content to get server start result (success/error, or nonexistent file means start failure). The timestamp can be used to identify this marker file's age in case of previous abnormal termination. Once server is normally shutdown, it can be removed as part of service stop. If anyone is interested in this, please take a look at the PR, and feel free to reply this or leave a comment. Thanks, > > Therefore, I would like to listen for your opinions for them. Any > other suggestion is certainly welcomed in mail or on jira. > > Best regards, > > Chao > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Chao Wang Software Engineer JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150713/a9bf9617/attachment-0001.html From cdewolf at redhat.com Mon Jul 13 04:06:58 2015 From: cdewolf at redhat.com (Carlo de Wolf) Date: Mon, 13 Jul 2015 10:06:58 +0200 Subject: [wildfly-dev] Wildfly start-up as service script depends on console log to determinate start result In-Reply-To: <557AD735.5020907@redhat.com> References: <5576F142.3030307@redhat.com> <55786983.2010500@redhat.com> <4128C564-7AFB-43D9-9D8A-AD6ABCB24BE1@redhat.com> <557AD735.5020907@redhat.com> Message-ID: <55A371A2.60004@redhat.com> On 06/12/2015 02:57 PM, David M. Lloyd wrote: > This is yet another good use case for an idea I proposed at the last > couple developer meeting: the idea of configurable "availability" > services, where you add a configuration which says "when these > components and/or configured services are available, perform this > action" where the action might be to notify a load balancer, perform a > notification to humans, or even drop a file to the filesystem (which > would be directly useful to this use case). > > Note (in case someone thinks this is a great idea and runs out to > implement it right away) that when I say "configured services" I do not > mean MSC service names; more like management capabilities where you have > a constrained namespace and each subsystem can contribute services to > this category. Wouldn't implementing a MSC service with dependencies be just the quick fix that covers the use case? :-) Carlo > > Also note that Java 9 adds limited support for signalling unrelated > processes, though at the moment on UNIX the signals are basically > limited to TERM and KILL. > > On 06/12/2015 07:06 AM, Jason T. Greene wrote: >>> On Jun 10, 2015, at 11:46 AM, Brian Stansberry wrote: >>> >>> So, what purpose is this fulfilling? >>> >>> 2) How does other software solve this problem? If it's solving a valid >>> problem, it seems like there would be a typical solution. >> The classic UNIX solution is that the daemon forks and returns, dropping a PID file of its child to disk, after it is done initializing and exits with an error code when there is a problem. >> >> Systemd added other approaches, where a daemon can signal systemd directly, or it can use dbus to send a message. >> >> The former can't be done efficiently in Java because it doesn't have a pure fork(), only an exec. Although it would be possible to emulate with an exec with an unacceptable hit to boot time. The latter options are too Linux specific. >> >> I think the best solution would be for us to add a signaling mechanism specifically for this purpose. We could use sun.misc.Signal (potentially an issue on Java 9), or we could exec the kill command to signal a process. >> >> We could also use a specially status file (e.g standalone.sh --start-status-file=blah) for a script to monitor. >> >> Thoughts? >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> From jorsol at gmail.com Mon Jul 13 04:10:31 2015 From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=) Date: Mon, 13 Jul 2015 08:10:31 +0000 Subject: [wildfly-dev] Wildfly start-up as service script depends on console log to determinate start result In-Reply-To: <55A3529B.4020706@redhat.com> References: <5576F142.3030307@redhat.com> <55A3529B.4020706@redhat.com> Message-ID: I don't like that deleteStartupMarker() is repeated on HostControllerService.java and ApplicationServerService.java The marker file should be just "startup-marker", or probably "wildfly- startup-marker". And if we go that road why not add another line with "message: Error message", that way it can be parsed by startup scripts and print the error directly. On Sun, Jul 12, 2015 at 11:55 PM Chao Wang wrote: > > > On 06/09/2015 09:59 PM, Chao Wang wrote: > > Hi all, > > The Wildfly start-up as service scripts wildfly-init-redhat.sh and wildfly-init-debian.sh > currently depend on a grep action of key message 'WFLYSRV0025:' in > console log to determinate whether service start is successful. The log > message indication is accurate, however, it's not that robust since user > can always remove console handler from logging subsystem. I have opened a > WFCORE enhancement jira https://issues.jboss.org/browse/WFCORE-747 for it. > > For the moment, I have tried three options, they're all not that perfect > to implement > > 1. Stay with exact log message, users need to define their jboss log > directory such as $JBOSS_HOME/standalone/log/server.log for standalone and > $JBOSS_HOME/domain/log/host-controller.log for domain instead of searching > in console log. This is more like another workaround since it is also volatile > once we update log message in future release.(EAP has 'JBAS015874:') > > 2. Use service pid, this is not precise because a long start-up can crash > in the last second. It needs to wait a suitable seconds before checking pid > existence. and still it can not avoid fake success in rare case just before > timeout. > > 3. Use read-attribute server-state through CLI connection as I did in Pull > Request on Jira. This is declined as it is possible that authentication is > required before connection. In such case, any non encrypted password is > not advised in configuration files. > > > I have opened a PR to change the log key message dependency in start > script https://github.com/wildfly/wildfly-core/pull/859 > > A jboss start marker file in temporary directory can be added to record > launch result and its timestamp when it starts. wildfly-init-redhat.sh / > wildfly-init-debian.sh will exam its content to get server start result > (success/error, or nonexistent file means start failure). The timestamp can > be used to identify this marker file's age in case of previous abnormal > termination. Once server is normally shutdown, it can be removed as part > of service stop. > > If anyone is interested in this, please take a look at the PR, and feel > free to reply this or leave a comment. > > Thanks, > > > Therefore, I would like to listen for your opinions for them. Any other > suggestion is certainly welcomed in mail or on jira. > > Best regards, > > Chao > > > _______________________________________________ > wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -- > Chao Wang > Software Engineer > JBoss by Red Hat > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150713/6dfdf5f4/attachment.html From tomaz.cerar at gmail.com Mon Jul 13 08:53:26 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 13 Jul 2015 14:53:26 +0200 Subject: [wildfly-dev] Using feature packs for custom distributions In-Reply-To: References: <1078508222.16648070.1436450251162.JavaMail.zimbra@redhat.com> Message-ID: On Thu, Jul 9, 2015 at 5:13 PM, Jason Greene wrote: > > For our use-case this would also be addressed by wildfly providing a > feature-pack definition that?s somewhere between servlet-feature-pack and > full-feature-pack - as long as it contains datasources support, and jaxrs > support ? > > I think this is a good idea, to skip optional deps. > Should we add another feature pack "wildfly-web" that would be near EE web profile? We could only have feature pack without corresponding distribution. This would allow downstream projects like keycloak to easier build custom distribution using such feature pack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150713/1fb7f8e2/attachment.html From stian at redhat.com Mon Jul 13 09:13:39 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 13 Jul 2015 09:13:39 -0400 (EDT) Subject: [wildfly-dev] Using feature packs for custom distributions In-Reply-To: References: <1078508222.16648070.1436450251162.JavaMail.zimbra@redhat.com> Message-ID: <2136328166.37140516.1436793219178.JavaMail.zimbra@redhat.com> As I see it the main issue with using core or servlets is the fact that we have to redefine modules. Currently AFAIK when pulling in a feature pack you end up pulling in all modules for that feature pack even if you disable subsystems/extensions that rely on those modules. Would it not be better to have individual subsystems define what modules they require and only pull in the required modules for the enabled subsystems/extensions? That would allow us to build on WF full and get all module definitions from there, while still reducing the size of our distribution. ----- Original Message ----- > From: "Toma? Cerar" > To: "Jason Greene" > Cc: wildfly-dev at lists.jboss.org, "keycloak dev" > Sent: Monday, 13 July, 2015 2:53:26 PM > Subject: Re: [wildfly-dev] Using feature packs for custom distributions > > > On Thu, Jul 9, 2015 at 5:13 PM, Jason Greene < jason.greene at redhat.com > > wrote: > > > > > For our use-case this would also be addressed by wildfly providing a > > feature-pack definition that?s somewhere between servlet-feature-pack and > > full-feature-pack - as long as it contains datasources support, and jaxrs > > support ? > > I think this is a good idea, to skip optional deps. > > > Should we add another feature pack "wildfly-web" that would be near EE web > profile? > We could only have feature pack without corresponding distribution. > This would allow downstream projects like keycloak to easier build custom > distribution using such feature pack. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From david.lloyd at redhat.com Mon Jul 13 09:23:08 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 13 Jul 2015 08:23:08 -0500 Subject: [wildfly-dev] Wildfly start-up as service script depends on console log to determinate start result In-Reply-To: <55A371A2.60004@redhat.com> References: <5576F142.3030307@redhat.com> <55786983.2010500@redhat.com> <4128C564-7AFB-43D9-9D8A-AD6ABCB24BE1@redhat.com> <557AD735.5020907@redhat.com> <55A371A2.60004@redhat.com> Message-ID: <55A3BBBC.70800@redhat.com> On 07/13/2015 03:06 AM, Carlo de Wolf wrote: > On 06/12/2015 02:57 PM, David M. Lloyd wrote: >> This is yet another good use case for an idea I proposed at the last >> couple developer meeting: the idea of configurable "availability" >> services, where you add a configuration which says "when these >> components and/or configured services are available, perform this >> action" where the action might be to notify a load balancer, perform a >> notification to humans, or even drop a file to the filesystem (which >> would be directly useful to this use case). >> >> Note (in case someone thinks this is a great idea and runs out to >> implement it right away) that when I say "configured services" I do not >> mean MSC service names; more like management capabilities where you have >> a constrained namespace and each subsystem can contribute services to >> this category. > > Wouldn't implementing a MSC service with dependencies be just the quick > fix that covers the use case? :-) Of course; however there aren't MSC services that represent services like entire WARs, and also, MSC service names are not API so if and when we change service names for e.g. servlets in future versions, things will break. The idea is to establish the function in terms of EE app, module, and component names, and subsystem/model-specific names rather than service names (which are really an implementation detail). For a particular example, it's very likely that we will change the way services are assigned to EJBs. > > Carlo > >> >> Also note that Java 9 adds limited support for signalling unrelated >> processes, though at the moment on UNIX the signals are basically >> limited to TERM and KILL. >> >> On 06/12/2015 07:06 AM, Jason T. Greene wrote: >>>> On Jun 10, 2015, at 11:46 AM, Brian Stansberry >>>> wrote: >>>> >>>> So, what purpose is this fulfilling? >>>> >>>> 2) How does other software solve this problem? If it's solving a valid >>>> problem, it seems like there would be a typical solution. >>> The classic UNIX solution is that the daemon forks and returns, >>> dropping a PID file of its child to disk, after it is done >>> initializing and exits with an error code when there is a problem. >>> >>> Systemd added other approaches, where a daemon can signal systemd >>> directly, or it can use dbus to send a message. >>> >>> The former can't be done efficiently in Java because it doesn't have >>> a pure fork(), only an exec. Although it would be possible to emulate >>> with an exec with an unacceptable hit to boot time. The latter >>> options are too Linux specific. >>> >>> I think the best solution would be for us to add a signaling >>> mechanism specifically for this purpose. We could use sun.misc.Signal >>> (potentially an issue on Java 9), or we could exec the kill command >>> to signal a process. >>> >>> We could also use a specially status file (e.g standalone.sh >>> --start-status-file=blah) for a script to monitor. >>> >>> Thoughts? >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> > -- - DML From bmcwhirt at redhat.com Mon Jul 13 10:02:05 2015 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Mon, 13 Jul 2015 10:02:05 -0400 Subject: [wildfly-dev] Using feature packs for custom distributions In-Reply-To: References: <1078508222.16648070.1436450251162.JavaMail.zimbra@redhat.com> Message-ID: <3DE1DB5E-9F74-4BE9-984A-877F462F37B6@redhat.com> >> For our use-case this would also be addressed by wildfly providing a feature-pack definition that?s somewhere between servlet-feature-pack and full-feature-pack - as long as it contains datasources support, and jaxrs support ? > > I think this is a good idea, to skip optional deps. This is what wildfly-swarm does. We consume the WF feature-packs, but only solve the tree from a few root module.xml?s to extract only the subset we need. And if it?s optional=?true?, we pretend we don?t need it. That helps a lot. Also, as soon as something pulls in weld, you?re pretty screwed, since weld then depends on most everything else, many times non-optionally. -Bob > >> >> Another thing is provisioning of feature packs, which I address in another email. >> >> >> - marko >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150713/291a9637/attachment-0001.html From stian at redhat.com Mon Jul 13 10:34:13 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 13 Jul 2015 10:34:13 -0400 (EDT) Subject: [wildfly-dev] Including Keycloak client adapters in WildFly 10 In-Reply-To: <1A8F606B-E548-4FD3-979E-819686D84922@redhat.com> References: <2083988224.31710463.1435923649086.JavaMail.zimbra@redhat.com> <1A8F606B-E548-4FD3-979E-819686D84922@redhat.com> Message-ID: <1019697788.37197427.1436798053853.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jason Greene" > To: "Stian Thorgersen" > Cc: "keycloak dev" , wildfly-dev at lists.jboss.org > Sent: Tuesday, 7 July, 2015 11:19:52 PM > Subject: Re: [wildfly-dev] Including Keycloak client adapters in WildFly 10 > > > > On Jul 3, 2015, at 6:40 AM, Stian Thorgersen wrote: > > > > Keycloak provides an adapter, including a WildFly extensions, to make it > > easier to add authentication to JavaEE applications with Keycloak. > > Sorry for my delay replying. Comments are inline: > > > > > It includes a few modules. Currently 8 Keycloak specific modules and one 1 > > third-party. The third-party is net.iharder.base64. > > We already have many Base64 implementations. It?s pretty easy to pull one in > with cut and paste. Java 8 also provides one, so that could be used. We can copy/paste it, but would it not be better to include one Base64 lib in WildFly than have everyone have their own? > > > > > As the WildFly extensions includes a deployment processor that configures > > the authentication method as well as dependencies for a deployment it's > > easy to add authentication to a JavaEE application. All you need to do is > > specify it in standalone.xml, for example: > > > > ... > > 675356d8-2b6b-4602-a74f-7079e0555885 > > You probably already did this, but such an attribute should support vault > usage as well so that credentials can be kept out of configs. No, pretty sure we don't, but we should > > > > > ... > > > > I'd like to explore if we can add this extension and the required modules > > directly to WildFly 10, rather than require users to add it themselves. > > Can you sync up with the elytron team? They are making other changes in this > area, which are not yet in 10, and I want to make sure thats all compatible. Will do, we need to have a sync with them asap in either case to make sure the Elytron SPIs cover all use-cases we need. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Mon Jul 13 10:38:21 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 13 Jul 2015 09:38:21 -0500 Subject: [wildfly-dev] Including Keycloak client adapters in WildFly 10 In-Reply-To: <1019697788.37197427.1436798053853.JavaMail.zimbra@redhat.com> References: <2083988224.31710463.1435923649086.JavaMail.zimbra@redhat.com> <1A8F606B-E548-4FD3-979E-819686D84922@redhat.com> <1019697788.37197427.1436798053853.JavaMail.zimbra@redhat.com> Message-ID: <55A3CD5D.6020202@redhat.com> On 7/13/15 9:34 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Jason Greene" >> To: "Stian Thorgersen" >> Cc: "keycloak dev" , wildfly-dev at lists.jboss.org >> Sent: Tuesday, 7 July, 2015 11:19:52 PM >> Subject: Re: [wildfly-dev] Including Keycloak client adapters in WildFly 10 >> >> >>> On Jul 3, 2015, at 6:40 AM, Stian Thorgersen wrote: >>> >>> Keycloak provides an adapter, including a WildFly extensions, to make it >>> easier to add authentication to JavaEE applications with Keycloak. >> >> Sorry for my delay replying. Comments are inline: >> >>> >>> It includes a few modules. Currently 8 Keycloak specific modules and one 1 >>> third-party. The third-party is net.iharder.base64. >> >> We already have many Base64 implementations. It?s pretty easy to pull one in >> with cut and paste. Java 8 also provides one, so that could be used. > > We can copy/paste it, but would it not be better to include one Base64 lib in WildFly than have everyone have their own? > Since WildFly 10 requires JDK 8, it uses the JDK one. >> >>> >>> As the WildFly extensions includes a deployment processor that configures >>> the authentication method as well as dependencies for a deployment it's >>> easy to add authentication to a JavaEE application. All you need to do is >>> specify it in standalone.xml, for example: >>> >>> ... >>> 675356d8-2b6b-4602-a74f-7079e0555885 >> >> You probably already did this, but such an attribute should support vault >> usage as well so that credentials can be kept out of configs. > > No, pretty sure we don't, but we should > >> >>> >>> ... >>> >>> I'd like to explore if we can add this extension and the required modules >>> directly to WildFly 10, rather than require users to add it themselves. >> >> Can you sync up with the elytron team? They are making other changes in this >> area, which are not yet in 10, and I want to make sure thats all compatible. > > Will do, we need to have a sync with them asap in either case to make sure the Elytron SPIs cover all use-cases we need. > >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From stian at redhat.com Mon Jul 13 10:43:33 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 13 Jul 2015 10:43:33 -0400 (EDT) Subject: [wildfly-dev] Including Keycloak client adapters in WildFly 10 In-Reply-To: <55A3CD5D.6020202@redhat.com> References: <2083988224.31710463.1435923649086.JavaMail.zimbra@redhat.com> <1A8F606B-E548-4FD3-979E-819686D84922@redhat.com> <1019697788.37197427.1436798053853.JavaMail.zimbra@redhat.com> <55A3CD5D.6020202@redhat.com> Message-ID: <1010486697.37205293.1436798613694.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Brian Stansberry" > To: wildfly-dev at lists.jboss.org > Sent: Monday, 13 July, 2015 4:38:21 PM > Subject: Re: [wildfly-dev] Including Keycloak client adapters in WildFly 10 > > On 7/13/15 9:34 AM, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Jason Greene" > >> To: "Stian Thorgersen" > >> Cc: "keycloak dev" , > >> wildfly-dev at lists.jboss.org > >> Sent: Tuesday, 7 July, 2015 11:19:52 PM > >> Subject: Re: [wildfly-dev] Including Keycloak client adapters in WildFly > >> 10 > >> > >> > >>> On Jul 3, 2015, at 6:40 AM, Stian Thorgersen wrote: > >>> > >>> Keycloak provides an adapter, including a WildFly extensions, to make it > >>> easier to add authentication to JavaEE applications with Keycloak. > >> > >> Sorry for my delay replying. Comments are inline: > >> > >>> > >>> It includes a few modules. Currently 8 Keycloak specific modules and one > >>> 1 > >>> third-party. The third-party is net.iharder.base64. > >> > >> We already have many Base64 implementations. It?s pretty easy to pull one > >> in > >> with cut and paste. Java 8 also provides one, so that could be used. > > > > We can copy/paste it, but would it not be better to include one Base64 lib > > in WildFly than have everyone have their own? > > > > Since WildFly 10 requires JDK 8, it uses the JDK one. We can't depend on JDK 8 for our core library as it's used by our other adapters. So I guess our best option is to copy/paste in that case. > > >> > >>> > >>> As the WildFly extensions includes a deployment processor that configures > >>> the authentication method as well as dependencies for a deployment it's > >>> easy to add authentication to a JavaEE application. All you need to do is > >>> specify it in standalone.xml, for example: > >>> > >>> ... > >>> 675356d8-2b6b-4602-a74f-7079e0555885 > >> > >> You probably already did this, but such an attribute should support vault > >> usage as well so that credentials can be kept out of configs. > > > > No, pretty sure we don't, but we should > > > >> > >>> > >>> ... > >>> > >>> I'd like to explore if we can add this extension and the required modules > >>> directly to WildFly 10, rather than require users to add it themselves. > >> > >> Can you sync up with the elytron team? They are making other changes in > >> this > >> area, which are not yet in 10, and I want to make sure thats all > >> compatible. > > > > Will do, we need to have a sync with them asap in either case to make sure > > the Elytron SPIs cover all use-cases we need. > > > >> > >> -- > >> Jason T. Greene > >> WildFly Lead / JBoss EAP Platform Architect > >> JBoss, a division of Red Hat > >> > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From tomaz.cerar at gmail.com Mon Jul 13 10:44:16 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 13 Jul 2015 16:44:16 +0200 Subject: [wildfly-dev] Including Keycloak client adapters in WildFly 10 In-Reply-To: <1019697788.37197427.1436798053853.JavaMail.zimbra@redhat.com> References: <2083988224.31710463.1435923649086.JavaMail.zimbra@redhat.com> <1A8F606B-E548-4FD3-979E-819686D84922@redhat.com> <1019697788.37197427.1436798053853.JavaMail.zimbra@redhat.com> Message-ID: On Mon, Jul 13, 2015 at 4:34 PM, Stian Thorgersen wrote: > We can copy/paste it, but would it not be better to include one Base64 lib > in WildFly than have everyone have their own? In WildFly 10 we finally managed to remove it as JDK8 provides it directly. In all older versions there ways jboss-common-core that included it and most parts of the server used it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150713/629afd4b/attachment.html From brian.stansberry at redhat.com Mon Jul 13 12:11:22 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 13 Jul 2015 11:11:22 -0500 Subject: [wildfly-dev] Recursive management resource removes Message-ID: <55A3E32A.3070200@redhat.com> tl;dr We're going to start ensuring that any time a resource is removed, all it's children are properly removed too. This will let users remove an entire profile from the domain config in one op, which in important now that we make it easier to clone an entire profile or include one profile in another. These features should mean people will be more likely to perform major configuration surgery via the management API instead of xml editing, and surgeons need to 'remove' large chunks. Long version Just an FYI on pending changes in how 'remove' management operations are handled in WildFly 10. First, any resource that represents persistent configuration must expose a no-arg 'remove' operation. This was an informal requirement before; now it's formal. Second, you'd think that if a resource is removed via a 'remove' op that we'd *always* ensure that all child resources are properly removed as well. "Properly" meaning necessary runtime changes are made (e.g. services removed), not just that the resource is dropped from the configuration model. But this isn't the case. There are a couple resources that explicitly reject the 'remove' request if their children haven't been removed first. There are others where the Stage.RUNTIME logic handling the removal of the child assumes the parent model is still present, which is an invalid assumption if the parent is removed in the same op. And there are *may* be some where the child resource is just dropped ignoring the need to clean up child services. With https://github.com/wildfly/wildfly-core/pull/880 and https://github.com/wildfly/wildfly/pull/7734 I'm changing this. Now the base handler class for 'remove' ops (AbstractRemoveStepHandler) will by default add steps to recursively remove any child resources before executing a step to remove the target resource. If for some reason you don't want a step added to remove a particular child, override the AbstractRemoveStepHandler.removeChildRecursively(PathElement child) method. For example, see [1]. This is expected to be a quite unusual thing to do. If your resource doesn't use AbstractRemoveStepHandler for implementing 'remove': 1) Why not? 2) You're responsible for implementing the same semantic. Note there are a couple remove handler impls that have implemented similar logic in a custom manner. Once a core release with WFCORE-808 in it is in full, that custom logic can be dropped. [1] https://github.com/bstansberry/wildfly/commit/7a046d7b99eeb1a73b53253786a35d9feabb0594#diff-66ba92875120259e1f20594aea124e88R33 [2] https://github.com/bstansberry/wildfly/commit/e64a1bd83b83e20f5f3964aece8df8252fa2622b#diff-dd540666d795f932922dd1da5ad8f798 -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From tomaz.cerar at gmail.com Mon Jul 13 17:26:14 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 13 Jul 2015 23:26:14 +0200 Subject: [wildfly-dev] Metrics & runtime attribute registration Message-ID: Hey guys, We had interesting discussion with Brian on https://github.com/wildfly/wildfly-core/pull/848#issuecomment-119778986 about how we register runtime/metric attribute on resources. There are many cases where subsystems only register attributes / resources only when server is booting into normal mode. but if it server is booted only to "admin mode" all that runtime/metrics attributes are not registered and as such not seen in the model. Registering runtime attributes only in normal mode can cause that results of :read-resource-description/read-resource wouldn't return attributes that are on resources if server is started in admin mode or even CLI standalone. Our metadata already provides information if attributes is runtime/metric/configuration. This can cause problems for tooling that relies on output of those two operations. Looking at current state of the code, we do use both ways of registering attributes either conditionally or always. This probably originates from times where there was no good api/way to mark attribute/resource as runtime. I am personally am in favor of always registering runtime attributes as this makes sure that user isn't surprised by some extra/missing attributes based on fact how it is starting the server. What do you guys think? Should we always register it or have it conditionally? -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150713/f0a0c9c3/attachment.html From hbraun at redhat.com Tue Jul 14 03:59:06 2015 From: hbraun at redhat.com (Heiko Braun) Date: Tue, 14 Jul 2015 09:59:06 +0200 Subject: [wildfly-dev] Recursive management resource removes In-Reply-To: <55A3E32A.3070200@redhat.com> References: <55A3E32A.3070200@redhat.com> Message-ID: +1 > On 13 Jul 2015, at 18:11, Brian Stansberry wrote: > > tl;dr > > We're going to start ensuring that any time a resource is removed, all > it's children are properly removed too. > > This will let users remove an entire profile from the domain config in > one op, which in important now that we make it easier to clone an entire > profile or include one profile in another. These features should mean > people will be more likely to perform major configuration surgery via > the management API instead of xml editing, and surgeons need to 'remove' > large chunks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150714/5c9c2634/attachment-0001.html From hbraun at redhat.com Tue Jul 14 04:00:32 2015 From: hbraun at redhat.com (Heiko Braun) Date: Tue, 14 Jul 2015 10:00:32 +0200 Subject: [wildfly-dev] Metrics & runtime attribute registration In-Reply-To: References: Message-ID: <8FD03E30-93C1-465F-91B2-2F7B42553E13@redhat.com> +1 for ?awalys' > On 13 Jul 2015, at 23:26, Toma? Cerar wrote: > > I am personally am in favor of always registering runtime attributes as this makes sure that user isn't surprised by some extra/missing > attributes based on fact how it is starting the server. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150714/007c61eb/attachment.html From ttarrant at redhat.com Tue Jul 14 07:06:43 2015 From: ttarrant at redhat.com (Tristan Tarrant) Date: Tue, 14 Jul 2015 12:06:43 +0100 Subject: [wildfly-dev] Using feature packs for custom distributions In-Reply-To: <1078508222.16648070.1436450251162.JavaMail.zimbra@redhat.com> References: <1078508222.16648070.1436450251162.JavaMail.zimbra@redhat.com> Message-ID: <55A4ED43.6050605@redhat.com> Hi Marko, I ran into the same issue recently and there is a thread on this mailing list about it [1]. I ended up working my way "down" from wildfly-full to infinispan server, since it involved less work and less trial and error. In our case we don't even want any of the servlet and web related stuff (i.e. undertow) since our frontend is Netty, but I'd much rather use wildfly-web as a base than our current solution (less stuff to remove == less things that can go wrong). One potential solution is to "fork" the upstream subsystems, even just for tweaking the module.xml (I know it's dangerous practice, but it has proven quite effective). Tristan [1] http://lists.jboss.org/pipermail/wildfly-dev/2015-May/003984.html On 09/07/2015 14:57, Marko Strukelj wrote: > > For Keycloak we?ve been trying to create a trimmed down distribution of Keycloak server, basing it on servlet-feature-pack rather than full-feature-pack, since we don?t need many of the subsystems. We?ve encountered some issues though that made us step back and stick to using full-feature-pack as a basis for Keycloak server distribution. If we find a way to address these issues in the future we?ll reconsider, but for now we don?t see much sense in basing our Keycloak distribution on servlet-feature-pack. > > There are two big isues for us: > > 1) Big module dependency trees > > Our goal was to reduce the distribution size by reducing the number of subsystems, and modules shipped. We guessed that since we don?t use EJB, JMS, WS - but basically just JAX-RS and datasources, the resulting distribution based on servlet-feature-pack wouldn?t get a lot bigger than OOTB servlet-feature-pack. But it turns out that enabling virtually any additional subsystem - in our case we want to use datasources, which are provided by org.jboss.as.connector - that pulls in around 90Mb of non-optional dependencies. That?s a lot just to get datasources support. > > What?s interesting is that adding a different subsystem support e.g. org.jboss.as.jaxrs pulls in the same dependency tree - i.e. adding JAXRS support pulls in the same dependency tree as adding Datasources support - that?s how intertwined the dependencies currently are. > > Using servlet-feature-pack for distributions that require some additional subsystems from full-feature-set is thus not very effective to significantly reduce custom distribution?s disk footprint. > > There is a tool I wrote as part of my analysis that I used to analyze the size of dependency trees: https://github.com/mstruk/keycloak-moduletool > > > 2) Staying in-sync with changes in full-feature-pack > > Creating a custom feature pack that is a subset of full-feature-pack requires copying module.xml files from wildfly/feature-pack source tree into custom feature pack source tree. Adding org.jboss.as.connector means copying over hundreds of modules (186 to be precise). As Wildfly development moves on, any changes to module.xml files have to be synced into the custom feature pack. That has the potential to be a huge maintenance burden, and a source of errors. One way to address this would be extended syntax somewhere in feature pack definition project to say something like: > > > > And that would replace copying over module directories, and module.xml files. And guarantee that things remain in-sync. > > For our use-case this would also be addressed by wildfly providing a feature-pack definition that?s somewhere between servlet-feature-pack and full-feature-pack - as long as it contains datasources support, and jaxrs support ... > > > Another thing is provisioning of feature packs, which I address in another email. > > > - marko > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From ttarrant at redhat.com Tue Jul 14 07:13:22 2015 From: ttarrant at redhat.com (Tristan Tarrant) Date: Tue, 14 Jul 2015 12:13:22 +0100 Subject: [wildfly-dev] Metrics & runtime attribute registration In-Reply-To: <8FD03E30-93C1-465F-91B2-2F7B42553E13@redhat.com> References: <8FD03E30-93C1-465F-91B2-2F7B42553E13@redhat.com> Message-ID: <55A4EED2.3060506@redhat.com> Yes, always is best as it provides a more uniform environment for tests too. Tristan On 14/07/2015 09:00, Heiko Braun wrote: > +1 for ?awalys' > > > >> On 13 Jul 2015, at 23:26, Toma? Cerar > > wrote: >> >> I am personally am in favor of always registering runtime attributes >> as this makes sure that user isn't surprised by some extra/missing >> attributes based on fact how it is starting the server. > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Tristan Tarrant Infinispan Lead JBoss, a division of Red Hat From paul.ferraro at redhat.com Tue Jul 14 07:54:25 2015 From: paul.ferraro at redhat.com (Paul Ferraro) Date: Tue, 14 Jul 2015 07:54:25 -0400 (EDT) Subject: [wildfly-dev] Recursive management resource removes In-Reply-To: <55A3E32A.3070200@redhat.com> References: <55A3E32A.3070200@redhat.com> Message-ID: <1922400062.38057680.1436874865164.JavaMail.zimbra@redhat.com> This is great. I had already proposed making this the default remove behavior for all clustering resources in https://github.com/wildfly/wildfly/pull/7407 via: https://github.com/pferraro/wildfly/blob/infinispan/clustering/common/src/main/java/org/jboss/as/clustering/controller/RemoveStepHandler.java Paul ----- Original Message ----- > From: "Brian Stansberry" > To: wildfly-dev at lists.jboss.org > Sent: Monday, July 13, 2015 12:11:22 PM > Subject: [wildfly-dev] Recursive management resource removes > > tl;dr > > We're going to start ensuring that any time a resource is removed, all > it's children are properly removed too. > > This will let users remove an entire profile from the domain config in > one op, which in important now that we make it easier to clone an entire > profile or include one profile in another. These features should mean > people will be more likely to perform major configuration surgery via > the management API instead of xml editing, and surgeons need to 'remove' > large chunks. > > Long version > > Just an FYI on pending changes in how 'remove' management operations are > handled in WildFly 10. > > First, any resource that represents persistent configuration must expose > a no-arg 'remove' operation. This was an informal requirement before; > now it's formal. > > Second, you'd think that if a resource is removed via a 'remove' op that > we'd *always* ensure that all child resources are properly removed as > well. "Properly" meaning necessary runtime changes are made (e.g. > services removed), not just that the resource is dropped from the > configuration model. > > But this isn't the case. There are a couple resources that explicitly > reject the 'remove' request if their children haven't been removed > first. There are others where the Stage.RUNTIME logic handling the > removal of the child assumes the parent model is still present, which is > an invalid assumption if the parent is removed in the same op. And there > are *may* be some where the child resource is just dropped ignoring the > need to clean up child services. > > With https://github.com/wildfly/wildfly-core/pull/880 and > https://github.com/wildfly/wildfly/pull/7734 I'm changing this. Now the > base handler class for 'remove' ops (AbstractRemoveStepHandler) will by > default add steps to recursively remove any child resources before > executing a step to remove the target resource. > > If for some reason you don't want a step added to remove a particular > child, override the > AbstractRemoveStepHandler.removeChildRecursively(PathElement child) > method. For example, see [1]. This is expected to be a quite unusual > thing to do. > > If your resource doesn't use AbstractRemoveStepHandler for implementing > 'remove': > > 1) Why not? > 2) You're responsible for implementing the same semantic. > > Note there are a couple remove handler impls that have implemented > similar logic in a custom manner. Once a core release with WFCORE-808 in > it is in full, that custom logic can be dropped. > > [1] > https://github.com/bstansberry/wildfly/commit/7a046d7b99eeb1a73b53253786a35d9feabb0594#diff-66ba92875120259e1f20594aea124e88R33 > [2] > https://github.com/bstansberry/wildfly/commit/e64a1bd83b83e20f5f3964aece8df8252fa2622b#diff-dd540666d795f932922dd1da5ad8f798 > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From brian.stansberry at redhat.com Tue Jul 14 09:45:55 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 14 Jul 2015 08:45:55 -0500 Subject: [wildfly-dev] Recursive management resource removes In-Reply-To: <1922400062.38057680.1436874865164.JavaMail.zimbra@redhat.com> References: <55A3E32A.3070200@redhat.com> <1922400062.38057680.1436874865164.JavaMail.zimbra@redhat.com> Message-ID: <55A51293.5060808@redhat.com> Yep. Those are the "couple remove handler impls that have implemented similar logic in a custom manner" I mentioned. Thanks for those; I saw them again when looking at the HASingleton stuff and that was the impetus to get this cleared up. I also shamelessly stole your approach of adding steps. On 7/14/15 6:54 AM, Paul Ferraro wrote: > This is great. I had already proposed making this the default remove behavior for all clustering resources in https://github.com/wildfly/wildfly/pull/7407 via: > https://github.com/pferraro/wildfly/blob/infinispan/clustering/common/src/main/java/org/jboss/as/clustering/controller/RemoveStepHandler.java > > Paul > > ----- Original Message ----- >> From: "Brian Stansberry" >> To: wildfly-dev at lists.jboss.org >> Sent: Monday, July 13, 2015 12:11:22 PM >> Subject: [wildfly-dev] Recursive management resource removes >> >> tl;dr >> >> We're going to start ensuring that any time a resource is removed, all >> it's children are properly removed too. >> >> This will let users remove an entire profile from the domain config in >> one op, which in important now that we make it easier to clone an entire >> profile or include one profile in another. These features should mean >> people will be more likely to perform major configuration surgery via >> the management API instead of xml editing, and surgeons need to 'remove' >> large chunks. >> >> Long version >> >> Just an FYI on pending changes in how 'remove' management operations are >> handled in WildFly 10. >> >> First, any resource that represents persistent configuration must expose >> a no-arg 'remove' operation. This was an informal requirement before; >> now it's formal. >> >> Second, you'd think that if a resource is removed via a 'remove' op that >> we'd *always* ensure that all child resources are properly removed as >> well. "Properly" meaning necessary runtime changes are made (e.g. >> services removed), not just that the resource is dropped from the >> configuration model. >> >> But this isn't the case. There are a couple resources that explicitly >> reject the 'remove' request if their children haven't been removed >> first. There are others where the Stage.RUNTIME logic handling the >> removal of the child assumes the parent model is still present, which is >> an invalid assumption if the parent is removed in the same op. And there >> are *may* be some where the child resource is just dropped ignoring the >> need to clean up child services. >> >> With https://github.com/wildfly/wildfly-core/pull/880 and >> https://github.com/wildfly/wildfly/pull/7734 I'm changing this. Now the >> base handler class for 'remove' ops (AbstractRemoveStepHandler) will by >> default add steps to recursively remove any child resources before >> executing a step to remove the target resource. >> >> If for some reason you don't want a step added to remove a particular >> child, override the >> AbstractRemoveStepHandler.removeChildRecursively(PathElement child) >> method. For example, see [1]. This is expected to be a quite unusual >> thing to do. >> >> If your resource doesn't use AbstractRemoveStepHandler for implementing >> 'remove': >> >> 1) Why not? >> 2) You're responsible for implementing the same semantic. >> >> Note there are a couple remove handler impls that have implemented >> similar logic in a custom manner. Once a core release with WFCORE-808 in >> it is in full, that custom logic can be dropped. >> >> [1] >> https://github.com/bstansberry/wildfly/commit/7a046d7b99eeb1a73b53253786a35d9feabb0594#diff-66ba92875120259e1f20594aea124e88R33 >> [2] >> https://github.com/bstansberry/wildfly/commit/e64a1bd83b83e20f5f3964aece8df8252fa2622b#diff-dd540666d795f932922dd1da5ad8f798 >> -- >> Brian Stansberry >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From brian.stansberry at redhat.com Tue Jul 14 10:43:41 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 14 Jul 2015 09:43:41 -0500 Subject: [wildfly-dev] Metrics & runtime attribute registration In-Reply-To: <55A4EED2.3060506@redhat.com> References: <8FD03E30-93C1-465F-91B2-2F7B42553E13@redhat.com> <55A4EED2.3060506@redhat.com> Message-ID: <55A5201D.8060804@redhat.com> I agree it's better to be uniform. There are a few things we need to resolve though before making this the policy. 1) An attribute description includes the 'nillable' field, which indicates whether a client can expect ModelType.UNDEFINED as the attribute value. With this change, every metric may return ModelType.UNDEFINED, since there cannot be a value if the process is in --admin-only mode. I see two options: a) For every metric we automatically record 'true' as the value for 'nillable'. The downside here is there is no way for a client to know if ModelType.UNDEFINED is a valid value when the process isn't in --admin-only. b) We leave things as is, but clients can check if the 'access-type' field has a value of 'metric' and use that to understand that the value may sometimes be ModelType.UNDEFINED regardless of what 'nillable' says. As I typed this I've formed a strong preference for a). To me b) is voodoo. 2) We reuse the same ResourceDefinition class on both a HostController and on a server. The use on a HostController is to define the domain level resource (e.g. /profile=*/subsystem=foo). When a normal extension is running on a host controller, it *should not* register metrics.[1] Just because we reuse a ResourceDefinition class doesn't mean the resource is the same, and a /profile=*/subsystem=foo resource is not the same as /subsystem=foo on a server. It's just a chunk of config and does not have metrics. The ExtensionContext has methods that can be used by extensions to figure out this kind of state stuff. As part of implementing this policy we'd change the behavior of the isRuntimeOnlyRegistrationValid() method so hopefully this kind of change would be transparent to existing extensions. 3) There a difference between registering a resource's definition and actually handling a request for the metric. I expect most metric read handlers are not written to function properly if the underlying services are not there. Hopefully most will "just work" based on extending some of our base handler classes, which will bypass execution in an --admin-only server. But we should expect that this change will result in some breakage that will have to be cleaned up as part of the work. Cheers, Brian [1] Unless it's a host extension; which we can get into if anyone cares. On 7/14/15 6:13 AM, Tristan Tarrant wrote: > Yes, always is best as it provides a more uniform environment for tests too. > > Tristan > > On 14/07/2015 09:00, Heiko Braun wrote: >> +1 for ?awalys' >> >> >> >>> On 13 Jul 2015, at 23:26, Toma? Cerar >> > wrote: >>> >>> I am personally am in favor of always registering runtime attributes >>> as this makes sure that user isn't surprised by some extra/missing >>> attributes based on fact how it is starting the server. >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jperkins at redhat.com Tue Jul 14 14:52:21 2015 From: jperkins at redhat.com (James R. Perkins) Date: Tue, 14 Jul 2015 11:52:21 -0700 Subject: [wildfly-dev] Metrics & runtime attribute registration In-Reply-To: References: Message-ID: <55A55A65.7010608@redhat.com> If the attribute is going to be undefined what is the benefit of having it in the model? If the tooling is looking for an attribute that doesn't exist wouldn't they just check for the existence with ModelNode.has()? I don't write any tooling so maybe I'm off :) I just don't see the benefit of adding an attribute that will always be UNDEFINED though. On 07/13/2015 02:26 PM, Toma? Cerar wrote: > Hey guys, > > We had interesting discussion with Brian on > https://github.com/wildfly/wildfly-core/pull/848#issuecomment-119778986 > about how we register runtime/metric attribute on resources. > > There are many cases where subsystems only register attributes / > resources only when server is booting into normal mode. > but if it server is booted only to "admin mode" all that > runtime/metrics attributes are not registered and as such not seen in > the model. > > Registering runtime attributes only in normal mode can cause that > results of :read-resource-description/read-resource > wouldn't return attributes that are on resources if server is started > in admin mode or even CLI standalone. > Our metadata already provides information if attributes is > runtime/metric/configuration. > > This can cause problems for tooling that relies on output of those two > operations. > > Looking at current state of the code, we do use both ways of > registering attributes either conditionally or always. > This probably originates from times where there was no good api/way to > mark attribute/resource as runtime. > > I am personally am in favor of always registering runtime attributes > as this makes sure that user isn't surprised by some extra/missing > attributes based on fact how it is starting the server. > > > What do you guys think? Should we always register it or have it > conditionally? > > -- > tomaz > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- James R. Perkins JBoss by Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150714/328d205a/attachment-0001.html From brian.stansberry at redhat.com Tue Jul 14 14:59:30 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 14 Jul 2015 13:59:30 -0500 Subject: [wildfly-dev] Metrics & runtime attribute registration In-Reply-To: <55A55A65.7010608@redhat.com> References: <55A55A65.7010608@redhat.com> Message-ID: <55A55C12.1090207@redhat.com> One thing that came up yesterday is generating code based on the model description. If you're doing that you want as much data as possible. You don't want to bring up an -admin-only process (say one embedded in the code generation tool) just to read and generate, and then find out you missed a bunch of attributes. On 7/14/15 1:52 PM, James R. Perkins wrote: > If the attribute is going to be undefined what is the benefit of having > it in the model? If the tooling is looking for an attribute that doesn't > exist wouldn't they just check for the existence with ModelNode.has()? > > I don't write any tooling so maybe I'm off :) I just don't see the > benefit of adding an attribute that will always be UNDEFINED though. > > On 07/13/2015 02:26 PM, Toma? Cerar wrote: >> Hey guys, >> >> We had interesting discussion with Brian on >> https://github.com/wildfly/wildfly-core/pull/848#issuecomment-119778986 >> >> about how we register runtime/metric attribute on resources. >> >> There are many cases where subsystems only register attributes / >> resources only when server is booting into normal mode. >> but if it server is booted only to "admin mode" all that >> runtime/metrics attributes are not registered and as such not seen in >> the model. >> >> Registering runtime attributes only in normal mode can cause that >> results of :read-resource-description/read-resource >> wouldn't return attributes that are on resources if server is started >> in admin mode or even CLI standalone. >> Our metadata already provides information if attributes is >> runtime/metric/configuration. >> >> This can cause problems for tooling that relies on output of those two >> operations. >> >> Looking at current state of the code, we do use both ways of >> registering attributes either conditionally or always. >> This probably originates from times where there was no good api/way to >> mark attribute/resource as runtime. >> >> I am personally am in favor of always registering runtime attributes >> as this makes sure that user isn't surprised by some extra/missing >> attributes based on fact how it is starting the server. >> >> >> What do you guys think? Should we always register it or have it >> conditionally? >> >> -- >> tomaz >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > 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 Senior Principal Software Engineer JBoss by Red Hat From tadamski at redhat.com Tue Jul 14 15:51:04 2015 From: tadamski at redhat.com (Tomasz Adamski) Date: Tue, 14 Jul 2015 15:51:04 -0400 (EDT) Subject: [wildfly-dev] WFLY-2422 or simplifying the remote outbound connection configuration for server to server communication In-Reply-To: <54FDAD5C.2030600@redhat.com> References: <54FDAD5C.2030600@redhat.com> Message-ID: <1802390050.7105075.1436903464047.JavaMail.zimbra@redhat.com> I belive that we need to deal with two problems: 1. Moving away configuration from application developer to server administrator. 2. Simplify the configuration so that most common scenarios can be consise and easy to understand. On the other hand we must assure that all valid use scenarios are still supported. My previous refactor dealt with the first point. Concept of profile was introduced which groups remote-outbound-connections and enables application developer to specify only the name of the profile. As Wolf mentioned the further things may to be improved: replication of configuration, cluster enabling and ability to use multiple profiles. Connection groups Regarding cluster configuration I believe that cluster properties should be moved from ejb-client-descriptor to remoting subsystem definition. Firstly, we will remove another part of server specific configuration from application deployer to server administrator. Secondly, it will allow to perform further simplifing configuration refactor. Regarding the second point, I believe that the problem of replication should not be handled using profiles - we should have a different configuration element for that. One possible solution that we discussed with Wolf was to create a remote-outbound-connection-group element which will gather together all r-o-cs that share the same configuration. Instead of: we would have: If user need to specify different configurations for different connections then he can still do it directly - that is create number of remote-outbound-connection not nested in any group. What's more the group may be used to group connections of one cluster. If we decide to group nodes from the cluster together then it would require that the same properties are used when connecting to each node in the cluster. Let's suppose that those connections are three possible points of entry to a cluster called "ejb-cluster". Currently application deployer has to specify the following configuration: According to Wolf it is a good practice for all nodes in the cluster to have the same configuration. If we can make an assumption than only such configuration is supported then we can use remote-outbound-connection-group to configure cluster as well. An example configuration may be: (...) Profiles Profile is an entity that can be understood by application deployer without need of knowing the configuration details. It would contain r-o-c and r-o-c groups (which can possibly represent a cluster). Currently user can address only one profile from jboss-ejb-client descriptor. This should be changed too - users should be able to specify many profiles in jboss-ejb-client. Profiles can be combinded in different ways and we were also discussing the possibility to introduce dependencies between profiles, but it needs to be discussed wheter there are use cases that require introduction of such design which introduces additional complexity. In proposed design application deployers can combine different profiles in their ejb-client-descriptors. Sample of proposed configuration: Remoting subsystem: Sample client configs: -- Tomasz Adamski Software Engineer JBoss by Red Hat ----- Oryginalna wiadomo?? ----- > Od: "Wolf-Dieter Fink" > Do: "tadam >> Tomasz Adamski" , "WildFly Dev" > DW: "Paul Ferraro" , "David M. Lloyd" , "Brad Maxwell" > , "Dennis Reed" , "Shay Matasaro" > Wys?ane: poniedzia?ek, 9 marzec 2015 15:25:32 > Temat: WFLY-2422 or simplifying the remote outbound connection configuration for server to server communication > > I start a request for simplifying the configuration for "in EE > application" clients and get rid of extra cluster configuration and > repeat properties many times. > Also the client should not need to have knowledge about the server > topology, there is no need to know how many servers there are or whether > they are clustered or not. > > Starting point in EAP6/WF8 is a application configuration like this: > https://github.com/wildfly/quickstart/blob/master/ejb-multi-server/app-main/ear/src/main/application/META-INF/jboss-ejb-client.xml? > > and a server side configuration like this: > > > connector-ref="default" security-realm="ApplicationRealm"/> > > name="remote-ejb-connection-1" > outbound-socket-binding-ref="remote-ejb-1" username="quickuser1" > security-realm="ejb-security-realm-1" protocol="http-remoting"> > > value="false"/> > > > > name="remote-ejb-connection-2" > outbound-socket-binding-ref="remote-ejb-2" username="quickuser2" > security-realm="ejb-security-realm-2" protocol="http-remoting"> > > value="false"/> > > > > > > > > > Tomasz did some refactoring (WF9) to use a profile from the application > perspective. The configuration is like this: > > jboss-ejb-client.xml > > > > > server profile: > thread-pool-name="default"> > > > outbound-connection-ref="remote-ejb-connection-1"/> > outbound-connection-ref="remote-ejb-connection-2"/> > > > > .... > > > name="remote-ejb-connection-1" > outbound-socket-binding-ref="remote-ejb-1" username="quickuser1" > security-realm="ejb-security-realm-1" protocol="http-remoting"> > > value="false"/> > > > > name="remote-ejb-connection-2" > outbound-socket-binding-ref="remote-ejb-2" username="quickuser2" > security-realm="ejb-security-realm-2" protocol="http-remoting"> > > value="false"/> > > > > > > > > With the current implementation there are some issues or > concerns/enhancements > - profile does not work with clusters > - not possible to have multiple profiles > - the properties/user must be still repeated > > > > From my point of view > - a cluster need to have the same property configuration, also different > users make no sense. Might work, but at least the cluster view will use > the same user > - a similar group of servers for the same application should not have > different properties/users as this will be error prone > - configuration should be as small and intuitive as possible > > My initial idea was to have a jboss-ejb-client.xml which reference > 'applications' to connect, that is similar to profiles > The server side as followed (don't care about the exact XML elements or > names) > > > > security-realm="ejb-security-realm-1" protocol="http-remoting"> > > value="false"/> > > > remote-ejb-1,remote-ejb2 > > name="remote-ejb-connection-X" > outbound-socket-binding-ref="remote-ejb-X" username="quickuser2" > security-realm="ejb-security-realm-2" protocol="http-remoting"> > > value="false"/> > > > > > > > In this case the profile use the user/security and properties for all > connections and the cluster as well. In this it is necessary to have the > same configuration for all the servers in the profile-bunch. > Another option I thought about is to use the user/properties in > as default and have the possibility to use a inner element > remote-outbound-connection, or a reference to remote-outbound-connection > which can override these, but I'm not sure whether this is needed. > > We (Tomasz Adamski and me) had a discussion about this and, technically > there is no problem with each approach. > > But ... > > I know that all the ejb-client stuff is subject to change and to prevent > from incompatible changes which are changed in every version > and from unnecessary work if the code will be changed before it will be > used at all > I think it will need to be discussed with others because of this. > > cheers > Wolf > From kabir.khan at jboss.com Tue Jul 14 16:33:36 2015 From: kabir.khan at jboss.com (Kabir Khan) Date: Tue, 14 Jul 2015 22:33:36 +0200 Subject: [wildfly-dev] Metrics & runtime attribute registration In-Reply-To: <55A55C12.1090207@redhat.com> References: <55A55A65.7010608@redhat.com> <55A55C12.1090207@redhat.com> Message-ID: <0DA02ECD-ACDD-4A62-B4A0-00EF814C0229@jboss.com> Could these be added to the registry with some special flag? My vague thought is that they would then be ?hidden? in admin-only mode, unless r-r-d is called with some new parameter. In normal mode they are visible. > On 14 Jul 2015, at 20:59, Brian Stansberry wrote: > > One thing that came up yesterday is generating code based on the model > description. If you're doing that you want as much data as possible. You > don't want to bring up an -admin-only process (say one embedded in the > code generation tool) just to read and generate, and then find out you > missed a bunch of attributes. > > On 7/14/15 1:52 PM, James R. Perkins wrote: >> If the attribute is going to be undefined what is the benefit of having >> it in the model? If the tooling is looking for an attribute that doesn't >> exist wouldn't they just check for the existence with ModelNode.has()? >> >> I don't write any tooling so maybe I'm off :) I just don't see the >> benefit of adding an attribute that will always be UNDEFINED though. >> >> On 07/13/2015 02:26 PM, Toma? Cerar wrote: >>> Hey guys, >>> >>> We had interesting discussion with Brian on >>> https://github.com/wildfly/wildfly-core/pull/848#issuecomment-119778986 >>> >>> about how we register runtime/metric attribute on resources. >>> >>> There are many cases where subsystems only register attributes / >>> resources only when server is booting into normal mode. >>> but if it server is booted only to "admin mode" all that >>> runtime/metrics attributes are not registered and as such not seen in >>> the model. >>> >>> Registering runtime attributes only in normal mode can cause that >>> results of :read-resource-description/read-resource >>> wouldn't return attributes that are on resources if server is started >>> in admin mode or even CLI standalone. >>> Our metadata already provides information if attributes is >>> runtime/metric/configuration. >>> >>> This can cause problems for tooling that relies on output of those two >>> operations. >>> >>> Looking at current state of the code, we do use both ways of >>> registering attributes either conditionally or always. >>> This probably originates from times where there was no good api/way to >>> mark attribute/resource as runtime. >>> >>> I am personally am in favor of always registering runtime attributes >>> as this makes sure that user isn't surprised by some extra/missing >>> attributes based on fact how it is starting the server. >>> >>> >>> What do you guys think? Should we always register it or have it >>> conditionally? >>> >>> -- >>> tomaz >>> >>> >>> >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> 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 > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Tue Jul 14 16:58:30 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 14 Jul 2015 15:58:30 -0500 Subject: [wildfly-dev] Metrics & runtime attribute registration In-Reply-To: <0DA02ECD-ACDD-4A62-B4A0-00EF814C0229@jboss.com> References: <55A55A65.7010608@redhat.com> <55A55C12.1090207@redhat.com> <0DA02ECD-ACDD-4A62-B4A0-00EF814C0229@jboss.com> Message-ID: <55A577F6.9030208@redhat.com> The registry already has data to distinguish these; they are registered as metrics. Heiko Braun had a good point today though. The issues we're discussing here are not limited to --admin-only. There are many metrics that can be disabled by setting some "statistics-enabled" attribute somewhere to false. Those metrics will still be registered though; they'll just not have a typical value. Since we have to deal with that case anyway, I don't see much value in hiding the attributes in --admin-only. Jason and I had a long chat in the WildFly hipchat room today though and for many metrics, returning null is silly. For example counters, where 0 is a perfectly reasonable value. Which further argues against hiding the metrics. If there are 3 categories of metrics: 1) Those with a natural 'initial value' like 0 to use if there is no runtime 2) Those that intuitively might have a null value, like a 'last-request-time' for some handler that's never handled a request 3) Those that don't naturally have a natural 'initial value' and also aren't intuitively nillable (say a "free-space" metric) How many are in the 3rd category and how big of a problem is it to return null anyway? On 7/14/15 3:33 PM, Kabir Khan wrote: > Could these be added to the registry with some special flag? > My vague thought is that they would then be ?hidden? in admin-only mode, unless r-r-d is called with some new parameter. > In normal mode they are visible. > >> On 14 Jul 2015, at 20:59, Brian Stansberry wrote: >> >> One thing that came up yesterday is generating code based on the model >> description. If you're doing that you want as much data as possible. You >> don't want to bring up an -admin-only process (say one embedded in the >> code generation tool) just to read and generate, and then find out you >> missed a bunch of attributes. >> >> On 7/14/15 1:52 PM, James R. Perkins wrote: >>> If the attribute is going to be undefined what is the benefit of having >>> it in the model? If the tooling is looking for an attribute that doesn't >>> exist wouldn't they just check for the existence with ModelNode.has()? >>> >>> I don't write any tooling so maybe I'm off :) I just don't see the >>> benefit of adding an attribute that will always be UNDEFINED though. >>> >>> On 07/13/2015 02:26 PM, Toma? Cerar wrote: >>>> Hey guys, >>>> >>>> We had interesting discussion with Brian on >>>> https://github.com/wildfly/wildfly-core/pull/848#issuecomment-119778986 >>>> >>>> about how we register runtime/metric attribute on resources. >>>> >>>> There are many cases where subsystems only register attributes / >>>> resources only when server is booting into normal mode. >>>> but if it server is booted only to "admin mode" all that >>>> runtime/metrics attributes are not registered and as such not seen in >>>> the model. >>>> >>>> Registering runtime attributes only in normal mode can cause that >>>> results of :read-resource-description/read-resource >>>> wouldn't return attributes that are on resources if server is started >>>> in admin mode or even CLI standalone. >>>> Our metadata already provides information if attributes is >>>> runtime/metric/configuration. >>>> >>>> This can cause problems for tooling that relies on output of those two >>>> operations. >>>> >>>> Looking at current state of the code, we do use both ways of >>>> registering attributes either conditionally or always. >>>> This probably originates from times where there was no good api/way to >>>> mark attribute/resource as runtime. >>>> >>>> I am personally am in favor of always registering runtime attributes >>>> as this makes sure that user isn't surprised by some extra/missing >>>> attributes based on fact how it is starting the server. >>>> >>>> >>>> What do you guys think? Should we always register it or have it >>>> conditionally? >>>> >>>> -- >>>> tomaz >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> -- >>> 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 >> Senior Principal Software Engineer >> JBoss by Red Hat >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From mstrukel at redhat.com Wed Jul 15 06:20:36 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Wed, 15 Jul 2015 06:20:36 -0400 (EDT) Subject: [wildfly-dev] Using feature packs for custom distributions In-Reply-To: <3DE1DB5E-9F74-4BE9-984A-877F462F37B6@redhat.com> References: <1078508222.16648070.1436450251162.JavaMail.zimbra@redhat.com> <3DE1DB5E-9F74-4BE9-984A-877F462F37B6@redhat.com> Message-ID: <788637847.19676911.1436955636449.JavaMail.zimbra@redhat.com> Thanks Bob for confirming that skipping optionals should work. My initial attempts at that were still pulling in the whole world, but I found it was due to a tiny bug in the tool I used that skipped some optionals but not all of them. Things look much more promising now ... ----- Original Message ----- > >> For our use-case this would also be addressed by wildfly providing a > >> feature-pack definition that?s somewhere between servlet-feature-pack and > >> full-feature-pack - as long as it contains datasources support, and jaxrs > >> support ? > > > > I think this is a good idea, to skip optional deps. > > This is what wildfly-swarm does. > > We consume the WF feature-packs, but only solve the tree from a few root > module.xml?s to extract only the subset we need. > > And if it?s optional=?true?, we pretend we don?t need it. That helps a lot. > > Also, as soon as something pulls in weld, you?re pretty screwed, since weld > then depends on most everything else, many times non-optionally. > > -Bob > > > > > > >> > >> Another thing is provisioning of feature packs, which I address in another > >> email. > >> > >> > >> - marko > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > > > -- > > Jason T. Greene > > WildFly Lead / JBoss EAP Platform Architect > > JBoss, a division of Red Hat > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > From mstrukel at redhat.com Wed Jul 15 06:25:19 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Wed, 15 Jul 2015 06:25:19 -0400 (EDT) Subject: [wildfly-dev] Using feature packs for custom distributions In-Reply-To: <55A4ED43.6050605@redhat.com> References: <1078508222.16648070.1436450251162.JavaMail.zimbra@redhat.com> <55A4ED43.6050605@redhat.com> Message-ID: <394044156.19677737.1436955919513.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Marko, > > I ran into the same issue recently and there is a thread on this mailing > list about it [1]. > I ended up working my way "down" from wildfly-full to infinispan server, > since it involved less work and less trial and error. Thanks for feedback. I also tried 'manually working down from full' approach but it was still too tedious and error prone. Best way to do this is to remove the human factor :) From bmcwhirt at redhat.com Wed Jul 15 09:31:08 2015 From: bmcwhirt at redhat.com (Bob McWhirter) Date: Wed, 15 Jul 2015 09:31:08 -0400 Subject: [wildfly-dev] Using feature packs for custom distributions In-Reply-To: <394044156.19677737.1436955919513.JavaMail.zimbra@redhat.com> References: <1078508222.16648070.1436450251162.JavaMail.zimbra@redhat.com> <55A4ED43.6050605@redhat.com> <394044156.19677737.1436955919513.JavaMail.zimbra@redhat.com> Message-ID: <666A7031-66FF-4FC1-95BE-7197545EAC50@redhat.com> I agree. Building up is much more successful, if you have a tool that can solve the graph. Start with the modules that match the modules you need, and walk from there, adding whatever is required, and you should get a good solution that is the minimum (modulo over-zealous dependencies) for what you?re trying to do. -Bob > On Jul 15, 2015, at 6:25 AM, Marko Strukelj wrote: > > > > ----- Original Message ----- >> Hi Marko, >> >> I ran into the same issue recently and there is a thread on this mailing >> list about it [1]. >> I ended up working my way "down" from wildfly-full to infinispan server, >> since it involved less work and less trial and error. > > Thanks for feedback. I also tried 'manually working down from full' approach but it was still too tedious and error prone. Best way to do this is to remove the human factor :) > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Wed Jul 15 14:26:26 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 15 Jul 2015 13:26:26 -0500 Subject: [wildfly-dev] Metrics & runtime attribute registration In-Reply-To: References: Message-ID: <55A6A5D2.8020506@redhat.com> Based on the discussion in this thread and some related chats in hipchat, I propose the requirements below for this general topic, and very much welcome comments. Note that this thread is about metrics, but handling of non-metric runtime-only attributes and operations all have the same concerns. I've placed an * next to requirements that involve some code change in the WildFly Core kernel. If we can reach a consensus around these requirements, that consensus can become a JIRA to implement the * items. I. If an Extension's initialize method is executing in a process type where the extension CAN install runtime services, the extension MUST register all metrics, other runtime-only attributes, and runtime-only operations, regardless of whether the process is running in --admin-only mode. II. If an Extension's initialize method is executing in a process type where the extension CANNOT install runtime services, the extension MUST NOT register any metrics, other runtime-only attributes, or runtime-only operations.[1] For example, most extensions will not register these when executing on a HostController. III.* The ExtensionContext.isRuntimeOnlyRegistrationValid() MUST return the proper value to tell the extension which of conditions I and II apply. IV.* The AttributeDefinition class MUST expose a 'public ModelNode getUndefinedMetricValue()' method and the builders for it MUST expose a 'public void setUndefinedMetricValue(ModelNode value)' method. (See VI.A below for the purpose of this.) A.* If assertions are enabled and an AttributeDefinition that is passed to ManagementResourceRegistration registerReadOnlyAttribute or registerReadWriteAttribute returns a defined ModelNode from getUndefinedMetricValue(), an AssertionError MUST be thrown. Non-metrics cannot provide undefined metric values. B.* If assertions are enabled and an AttributeDefinition that is passed to ManagementResourceRegistration registerMetric returns a defined ModelNode from getDefaultValue(), an AssertionError MUST be thrown. Metrics cannot provide default values. C.* If assertions are enabled and an AttributeDefinition that is passed to ManagementResourceRegistration registerMetric returns a defined ModelNode from getUndefinedMetricValue() and also returns 'true' from isAllowNull(), an AssertionError MUST be thrown. This is an inconsistent setting, as the undefined metric value will ensure the client never sees an undefined result. V. The read-attribute handler for a metric or runtime-only attribute MUST set a result value consistent with the attribute description regardless of whether the expected runtime services are disabled due to running in --admin-only or some other configuration option such as a 'statistics-enabled' attribute being set to 'false'. Specifically, if the handler might not set a defined value in that situation, the isAllowNull() method from the attribute's AttributeDefinition MUST return 'true'. VI. The read-attribute handler for metrics that have a logical defined value even if runtime services are not present SHOULD set that value as the result when runtime services are not present. For example, for many 'counter' metrics a value of 0 is a logical defined value. A. The read-attribute handler for such a metric MAY choose to not set a result value itself when there are no runtime services, and instead delegate to the kernel to have the kernel set the result. To configure such a delegation, the AttributeDefinition for the metric must return a defined value from its getUndefinedMetricValue() method. (See IV.) B.* The kernel's handler for read-attribute MUST check if the registered handler for the attribute has not set a defined result. If it has not, and the attribute is a metric, and its definition's getUndefinedMetricValue() method returns a defined value, the kernel handler must set that value as the result. This behavior MUST occur regardless of the value of any 'include-defaults' parameter passed to the hander. The 'include-defaults' parameter is unrelated to metrics. VII. The read-attribute handler for metrics that do not have a logical defined value if runtime services are not present SHOULD return an undefined result and SHOULD NOT return an arbitrary meaningless value such as -1 or Integer.MAX_VALUE. This is not a MUST/MUST NOT requirement because it is understood that backwards compatibility requirements may prevent changes to some attributes, and also that some integrated libraries may return such values without the subsystem handler's being aware of that. VIII. The read-attribute handler for a custom runtime-only operation MUST set a result value consistent with the operation description regardless of whether the expected runtime services are disabled due to running in --admin-only or some other configuration option. Specifically, if the handler might not set a defined value in that situation, the isReplyAllowNull() method from the attribute's OperationDefinition MUST return 'true'. A. However, it is permissible for a custom runtime-only operation handler to throw an OperationFailedException in this situation. The 'runtime-only'=>true entry in the operation's descriptive metadata provides an indication to callers that this is a possible result. I think that's about it. ;) [1] At some point in the future the restriction on runtime-only operations may be lifted, in order to support executing the operation on all servers in a domain. On 7/13/15 4:26 PM, Toma? Cerar wrote: > Hey guys, > > We had interesting discussion with Brian on > https://github.com/wildfly/wildfly-core/pull/848#issuecomment-119778986 > about how we register runtime/metric attribute on resources. > > There are many cases where subsystems only register attributes / > resources only when server is booting into normal mode. > but if it server is booted only to "admin mode" all that runtime/metrics > attributes are not registered and as such not seen in the model. > > Registering runtime attributes only in normal mode can cause that > results of :read-resource-description/read-resource > wouldn't return attributes that are on resources if server is started in > admin mode or even CLI standalone. > Our metadata already provides information if attributes is > runtime/metric/configuration. > > This can cause problems for tooling that relies on output of those two > operations. > > Looking at current state of the code, we do use both ways of registering > attributes either conditionally or always. > This probably originates from times where there was no good api/way to > mark attribute/resource as runtime. > > I am personally am in favor of always registering runtime attributes as > this makes sure that user isn't surprised by some extra/missing > attributes based on fact how it is starting the server. > > > What do you guys think? Should we always register it or have it > conditionally? > > -- > tomaz > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From jason.greene at redhat.com Wed Jul 15 18:11:53 2015 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 15 Jul 2015 17:11:53 -0500 Subject: [wildfly-dev] Feature pack provisioning In-Reply-To: <930099469.16650706.1436450574022.JavaMail.zimbra@redhat.com> References: <930099469.16650706.1436450574022.JavaMail.zimbra@redhat.com> Message-ID: <031C9ABB-1162-49A2-84D4-1E88A292C641@redhat.com> The feature-pack build tool is a tool thats intended for creating WildFly distributions (#1), its not intended to create layered project/products[A] / overlays (#2). For #2, the solution is really just packaging a subsystem in an extension jar, and thats something easily achieved with just the standard maven tools. I can certainly see why you would want to do #1 or #2, but I have a hard time seeing why you would want to do both. As to #3, the notion of a runtime provisioning system similar to something like a yum tool is a long term goal, which I totally agree we need, but its going to be a while before we can get there (Definitely not 10 nor 11). Alexey has been assembling requirements for it, and has some ideas around the packaging format. We really want to get it right, so the plan is to let it grow organically until its proven to be a solid system, and only then switch to it. [A] https://developer.jboss.org/hfurl/redirectToHFURL.jspa?url=/docs/DOC-47927¶ms= > On Jul 9, 2015, at 9:02 AM, Marko Strukelj wrote: > > > Currently wildfly-server-provisioning-maven-plugin always generates a full Wildfly distribution. For Keycloak project we have three different cases of provisioning, and it would be great to be able to cover it with a common wildfly provided tool: > > 1) full server distribution > 2) overlay distribution (unzip into existing OOTB Wildfly distribution - your problem if you use unsupported Wildfly version) > 3) provision into existing Wildfly server detecting version mismatches, and configuring existing and additional subsystems for Keycloak to run properly. > > > First one is what?s currently supported, and what we use. > > Second one is what we currently hack up by extracting modules directory from (1) - it would support this use case better if wildfly-server-provisioning-maven-plugin could generate 'modules only' for example. > > The third one requires a CLI installer tool. I?m not aware that currently there is something for that, and we are loath to develop one from scratch. > > Is it realistic to expect 2) and 3) in not so distant future? > > > - marko > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From david.lloyd at redhat.com Thu Jul 16 17:08:08 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 16 Jul 2015 16:08:08 -0500 Subject: [wildfly-dev] How to contribute pull requests to WildFly Message-ID: <55A81D38.1070009@redhat.com> Since migrating to git, and a review-oriented contribution structure, we've seen a massive improvement in the quality and quantity of community contribution in both WildFly itself and its affiliated projects. However, while we have lots of documents about how to get the WildFly code, hack on it, use git to make a branch, submit a pull request, etc., one thing rarely (if ever) talked about is any kind of standards as to how to actually build and structure your pull requests, so I'm going to establish that right now. I have a few reasons for doing this. First, the reviewers are stretched thin - very thin. This has several bad effects, including (but not limited to): * Pull requests sitting in the queue for extended periods of time * Giant pull requests getting less review than small pull requests * Pull requests receiving highly variable quality-of-review Secondly, we see problematic pull requests in a wide variety of shapes and sizes, from the single-unreviewable-mega-commit PR to the thousand-tiny-commit PR to the mixed-form-and-function-commit PR, as well as some stealthier cases like the build-is-broken-between-commits PR. Thirdly, the project has reached a size and scope where we really need to have more eyes on every change - as many as possible in fact. To that effect, and borrowing some concepts heavily from the Linux Kernel project's documentation [1], I offer this. You're welcome. (For background on how to get started with contribution, the hacking guide [2] is still the best place to start; after any initial discussion, I'll probably throw this up alongside that.) WildFly Contribution and Pull Request Standards ----------------------------------------------- While a complete git tutorial is far, far out of scope of this guide, there are a few important rules and guidelines to adhere to when creating a pull request for WildFly or one of its constituent or related sub-projects. 1) Describe the pull request adequately. The description *should* include a JIRA number directly from the project in question, whose corresponding JIRA issue will in turn have been linked to the pull request you are just now creating. The description *should* also include a decent, human-readable summary of what is changing. Proper spelling and grammar is a plus! 2) Make sure it builds and tests pass *first*. It is highly annoying to reviewers when they find they've spent a great deal of time reviewing some code only to discover that it doesn't even compile. In particular, it's common for a patch to trip CheckStyle if it hadn't been previously compile-tested at the least. While it is tempting to rely on the automated CI/GitHub integration to do our build and test for us (and I'm guilty of having done this too), it generally just causes trouble, so please don't do it! 3) Separate your changes - but not *too* much. This comes directly from [1], and I agree with it 100%: "Separate each _logical change_ into a separate patch. "For example, if your changes include both bug fixes and performance enhancements for a single driver, separate those changes into two or more patches. If your changes include an API update, and a new driver which uses that new API, separate those into two patches. "On the other hand, if you make a single change to numerous files, group those changes into a single patch. Thus a single logical change is contained within a single patch. "The point to remember is that each patch should make an easily understood change that can be verified by reviewers. Each patch should be justifiable on its own merits. "If one patch depends on another patch in order for a change to be complete, that is OK. Simply note "this patch depends on patch X" in your patch description. "When dividing your change into a series of patches, take special care to ensure that [WildFly] builds and runs properly after each patch in the series. Developers using "git bisect" to track down a problem can end up splitting your patch series at any point; they will not thank you if you introduce bugs in the middle. "If you cannot condense your patch set into a smaller set of patches, then only post say 15 or so at a time and wait for review and integration." I also want to emphasize how important it is to separate *functional* and *non-functional* changes. The latter category includes reformatting (which generally should *not* be done without a strong justification). 4) Avoid massive and/or "stream of consciousness" branches We all know that development can sometimes be an iterative process, and we learn as we go. Nonetheless, we do not need or want a complete record of all the highs and lows in the history of every change (for example, an "add foobar" commit followed later by a "remove foobar" commit in the same PR) - particularly for large changes or in large projects (like WildFly proper). It is good practice for such change authors to go back and rearrange and/or restructure the commits of a pull request such that they incrementally introduce the change in a logical manner, as one single conceptual change per PR. If a PR consists of dozens or hundreds of nontrivial commits, you will want to strongly consider dividing it up into multiple PRs, as PRs of this size simply cannot be effectively reviewed. They will either be merged without adequate review, or outright ignored or closed. Which one is worse, I leave to your imagination. 5) Pay attention and respond to review comments While in general it is my experience that WildFly contributors are good about this, I'm going to quote this passage from [1] regardless: "Your patch will almost certainly get comments from reviewers on ways in which the patch can be improved. You must respond to those comments; ignoring reviewers is a good way to get ignored in return. [...] "Be sure to tell the reviewers what changes you are making and to thank them for their time. Code review is a tiring and time-consuming process, and reviewers sometimes get grumpy. Even in that case, though, respond politely and address the problems they have pointed out." In addition, when something needs to be changed, the proper manner to do so is generally to modify the original commit, not to add more commits to the chain to fix issues as they're reported. See (4). 6) Don't get discouraged It may come to pass that you have to iterate on your pull request many times before it is considered acceptable. Don't be discouraged by this - instead, consider that to be a sign that the reviewers care highly about the quality of the code base. At the same time though, consider that it is frustrating for reviewers to have to say the same things over and over again, so please do take care to provide as high-quality submissions as possible, and see (5)! 7) You can review code too! You don't have to be an official reviewer in order to review a pull request. If you see a pull request dealing with an area you are familiar with, feel free to examine it and comment as needed. In addition, *all* pull requests need to be reviewed for basic (non-machine-verifiable) correctness, including noticing bad code, NPE risks, and anti-patterns as well as "boring stuff" like spelling and grammar and documentation. 8) On major refactorings When doing major and/or long-term refactors, while rare, it is possible that the above constraints become impractical, especially with regard to grouping changes. In this case, you can use a work branch on a (GitHub) fork of WildFly, applying the above rules in micro-scale to just that branch. In this case you could possibly ask a reviewer to also review some or all of the pull requests to that branch. Merge commits would then be used to periodically synchronize with upstream. In this way, when the long-term branch is ready to "come home" to the main branch, the reviewers may have a good idea that the (potentially quite numerous) changes in the work branch have been reviewed already. [1] https://www.kernel.org/doc/Documentation/SubmittingPatches [2] https://developer.jboss.org/wiki/HackingOnWildFly -- - DML From stian at redhat.com Fri Jul 17 04:00:52 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 17 Jul 2015 04:00:52 -0400 (EDT) Subject: [wildfly-dev] Feature pack provisioning In-Reply-To: <031C9ABB-1162-49A2-84D4-1E88A292C641@redhat.com> References: <930099469.16650706.1436450574022.JavaMail.zimbra@redhat.com> <031C9ABB-1162-49A2-84D4-1E88A292C641@redhat.com> Message-ID: <1204482943.40886040.1437120052439.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jason Greene" > To: "Marko Strukelj" > Cc: "keycloak dev" , "WildFly Developers" > Sent: Thursday, 16 July, 2015 12:11:53 AM > Subject: Re: [wildfly-dev] Feature pack provisioning > > The feature-pack build tool is a tool thats intended for creating WildFly > distributions (#1), its not intended to create layered project/products[A] / > overlays (#2). For #2, the solution is really just packaging a subsystem in > an extension jar, and thats something easily achieved with just the standard > maven tools. > > I can certainly see why you would want to do #1 or #2, but I have a hard time > seeing why you would want to do both. #1 is our standalone Keycloak server distribution - this is the recommended distribution for production or non-JEE developers #2 is intended to be used by JEE developers so they can have the KC server bits available in a single WF instance for development - this is intended as a distribution for JEE developers only > > As to #3, the notion of a runtime provisioning system similar to something > like a yum tool is a long term goal, which I totally agree we need, but its > going to be a while before we can get there (Definitely not 10 nor 11). > Alexey has been assembling requirements for it, and has some ideas around > the packaging format. We really want to get it right, so the plan is to let > it grow organically until its proven to be a solid system, and only then > switch to it. > > [A] > https://developer.jboss.org/hfurl/redirectToHFURL.jspa?url=/docs/DOC-47927¶ms= > > On Jul 9, 2015, at 9:02 AM, Marko Strukelj wrote: > > > > > > Currently wildfly-server-provisioning-maven-plugin always generates a full > > Wildfly distribution. For Keycloak project we have three different cases > > of provisioning, and it would be great to be able to cover it with a > > common wildfly provided tool: > > > > 1) full server distribution > > 2) overlay distribution (unzip into existing OOTB Wildfly distribution - > > your problem if you use unsupported Wildfly version) > > 3) provision into existing Wildfly server detecting version mismatches, and > > configuring existing and additional subsystems for Keycloak to run > > properly. > > > > > > First one is what?s currently supported, and what we use. > > > > Second one is what we currently hack up by extracting modules directory > > from (1) - it would support this use case better if > > wildfly-server-provisioning-maven-plugin could generate 'modules only' for > > example. > > > > The third one requires a CLI installer tool. I?m not aware that currently > > there is something for that, and we are loath to develop one from scratch. > > > > Is it realistic to expect 2) and 3) in not so distant future? > > > > > > - marko > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From rory.odonnell at oracle.com Fri Jul 17 08:49:59 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 17 Jul 2015 13:49:59 +0100 Subject: [wildfly-dev] Early Access builds for JDK 8u60 b24 and JDK 9 b72 are available on java.net Message-ID: <55A8F9F7.6070300@oracle.com> Hi Jason/Tomaz, Early Access build for JDK 8u60 b24 is available on java.net, summary of changes are listed here. As we enter the later phases of development for JDK 8u60, please log any show stoppers as soon as possible. Early Access build for JDK 9 b72 is available on java.net, summary of changes are listed here . Note: b72 includes 8081708 - Change default GC for server configurations to G1 As described in JEP 248 , switching to a low-pause collector in JDK 9 such as G1 should provide a better overall experience, for most users, than a throughput-oriented collector such as the Parallel GC, which is currently the default. A call for feedback and data points regarding this change went out on the hotspot-dev mailing list, where such input should be provided. 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/20150717/c341dade/attachment.html From jason.greene at redhat.com Fri Jul 17 12:26:03 2015 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 17 Jul 2015 11:26:03 -0500 Subject: [wildfly-dev] The CI Inquisition! Message-ID: Hello Everyone! Over the last few years we have attempted to get a grip on the intermittent test failures we see in CI almost every run, and have attempted various policies which were poorly enforced. This was mainly due to an understanding of tight deadline, but also a concern that strict enforcement would damage our test coverage. I would find myself holding out in hope that over time we would see these issues decrease. Unfortunately that hope was misplaced, and the simple truth is that coverage is already harmed, because no one pays attention to the intermittent fails, since they are treated as noise and not a true defect. I think we have no other option but to @Ignore any and every intermittent test, no matter the number or area they appear in. So unless someone can propose another workable strategy, intermittent tests should be disabled immediately by anyone that is impacted by them (reviewers, contributors, whoever). To do this, a simple short independent PR should be sent in, and a note should be left in a comment to the component lead of the area tested (using github?s super cool @user syntax). The component lead can then act on the message and choose whether to open and assign a JIRA to have it fixed, to ignore it, to delete it, to rewrite, etc. The intention is that the process of disabling an intermittent test should be as minimal effort as possible. In order for a known intermittent test to be reenabled, it needs to be shown that it is no longer intermittent by completing many full testsuite runs successfully. Anyone that needs it can request a custom CI job run for this purpose. Finally, if you are a saint and decide to fix an intermittent failing test, but have trouble reproducing it, feel free to raise the topic in the WildFly HipChat and we can come up with a solution like custom debug test jobs that can get you the info you need. Thoughts? -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From david.lloyd at redhat.com Fri Jul 17 12:36:37 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 17 Jul 2015 11:36:37 -0500 Subject: [wildfly-dev] The CI Inquisition! In-Reply-To: References: Message-ID: <55A92F15.1020000@redhat.com> Great! These tests are an endless source of annoyance. On 07/17/2015 11:26 AM, Jason Greene wrote: > Hello Everyone! > > Over the last few years we have attempted to get a grip on the intermittent test failures we see in CI almost every run, and have attempted various policies which were poorly enforced. This was mainly due to an understanding of tight deadline, but also a concern that strict enforcement would damage our test coverage. I would find myself holding out in hope that over time we would see these issues decrease. > > Unfortunately that hope was misplaced, and the simple truth is that coverage is already harmed, because no one pays attention to the intermittent fails, since they are treated as noise and not a true defect. I think we have no other option but to @Ignore any and every intermittent test, no matter the number or area they appear in. > > So unless someone can propose another workable strategy, intermittent tests should be disabled immediately by anyone that is impacted by them (reviewers, contributors, whoever). To do this, a simple short independent PR should be sent in, and a note should be left in a comment to the component lead of the area tested (using github?s super cool @user syntax). The component lead can then act on the message and choose whether to open and assign a JIRA to have it fixed, to ignore it, to delete it, to rewrite, etc. The intention is that the process of disabling an intermittent test should be as minimal effort as possible. > > In order for a known intermittent test to be reenabled, it needs to be shown that it is no longer intermittent by completing many full testsuite runs successfully. Anyone that needs it can request a custom CI job run for this purpose. > > Finally, if you are a saint and decide to fix an intermittent failing test, but have trouble reproducing it, feel free to raise the topic in the WildFly HipChat and we can come up with a solution like custom debug test jobs that can get you the info you need. > > Thoughts? > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- - DML From fjuma at redhat.com Fri Jul 17 13:49:32 2015 From: fjuma at redhat.com (Farah Juma) Date: Fri, 17 Jul 2015 13:49:32 -0400 (EDT) Subject: [wildfly-dev] WildFly 10.0.0.Alpha5 is now on OpenShift In-Reply-To: <626393534.28255265.1437155297648.JavaMail.zimbra@redhat.com> Message-ID: <58585605.28255473.1437155372546.JavaMail.zimbra@redhat.com> As usual, see https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-10 to get started. From david.lloyd at redhat.com Fri Jul 17 14:01:12 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 17 Jul 2015 13:01:12 -0500 Subject: [wildfly-dev] How to contribute pull requests to WildFly In-Reply-To: <55A81D38.1070009@redhat.com> References: <55A81D38.1070009@redhat.com> Message-ID: <55A942E8.8010004@redhat.com> I've published a copy of this on JBoss.org here: https://developer.jboss.org/wiki/WildFlyPullRequestStandardsAndGuidelines On 07/16/2015 04:08 PM, David M. Lloyd wrote: > Since migrating to git, and a review-oriented contribution structure, > we've seen a massive improvement in the quality and quantity of > community contribution in both WildFly itself and its affiliated > projects. However, while we have lots of documents about how to get the > WildFly code, hack on it, use git to make a branch, submit a pull > request, etc., one thing rarely (if ever) talked about is any kind of > standards as to how to actually build and structure your pull requests, > so I'm going to establish that right now. > > I have a few reasons for doing this. First, the reviewers are stretched > thin - very thin. This has several bad effects, including (but not > limited to): > > * Pull requests sitting in the queue for extended periods of time > * Giant pull requests getting less review than small pull requests > * Pull requests receiving highly variable quality-of-review > > Secondly, we see problematic pull requests in a wide variety of shapes > and sizes, from the single-unreviewable-mega-commit PR to the > thousand-tiny-commit PR to the mixed-form-and-function-commit PR, as > well as some stealthier cases like the build-is-broken-between-commits PR. > > Thirdly, the project has reached a size and scope where we really need > to have more eyes on every change - as many as possible in fact. > > To that effect, and borrowing some concepts heavily from the Linux > Kernel project's documentation [1], I offer this. You're welcome. > > (For background on how to get started with contribution, the hacking > guide [2] is still the best place to start; after any initial > discussion, I'll probably throw this up alongside that.) > > WildFly Contribution and Pull Request Standards > ----------------------------------------------- > While a complete git tutorial is far, far out of scope of this guide, > there are a few important rules and guidelines to adhere to when > creating a pull request for WildFly or one of its constituent or related > sub-projects. > > 1) Describe the pull request adequately. > > The description *should* include a JIRA number directly from the project > in question, whose corresponding JIRA issue will in turn have been > linked to the pull request you are just now creating. The description > *should* also include a decent, human-readable summary of what is > changing. Proper spelling and grammar is a plus! > > 2) Make sure it builds and tests pass *first*. > > It is highly annoying to reviewers when they find they've spent a great > deal of time reviewing some code only to discover that it doesn't even > compile. In particular, it's common for a patch to trip CheckStyle if > it hadn't been previously compile-tested at the least. > > While it is tempting to rely on the automated CI/GitHub integration to > do our build and test for us (and I'm guilty of having done this too), > it generally just causes trouble, so please don't do it! > > 3) Separate your changes - but not *too* much. > > This comes directly from [1], and I agree with it 100%: > > "Separate each _logical change_ into a separate patch. > > "For example, if your changes include both bug fixes and performance > enhancements for a single driver, separate those changes into two > or more patches. If your changes include an API update, and a new > driver which uses that new API, separate those into two patches. > > "On the other hand, if you make a single change to numerous files, > group those changes into a single patch. Thus a single logical change > is contained within a single patch. > > "The point to remember is that each patch should make an easily understood > change that can be verified by reviewers. Each patch should be justifiable > on its own merits. > > "If one patch depends on another patch in order for a change to be > complete, that is OK. Simply note "this patch depends on patch X" > in your patch description. > > "When dividing your change into a series of patches, take special care to > ensure that [WildFly] builds and runs properly after each patch in the > series. Developers using "git bisect" to track down a problem can end up > splitting your patch series at any point; they will not thank you if you > introduce bugs in the middle. > > "If you cannot condense your patch set into a smaller set of patches, > then only post say 15 or so at a time and wait for review and integration." > > I also want to emphasize how important it is to separate *functional* > and *non-functional* changes. The latter category includes reformatting > (which generally should *not* be done without a strong justification). > > 4) Avoid massive and/or "stream of consciousness" branches > > We all know that development can sometimes be an iterative process, and > we learn as we go. Nonetheless, we do not need or want a complete > record of all the highs and lows in the history of every change (for > example, an "add foobar" commit followed later by a "remove foobar" > commit in the same PR) - particularly for large changes or in large > projects (like WildFly proper). It is good practice for such change > authors to go back and rearrange and/or restructure the commits of a > pull request such that they incrementally introduce the change in a > logical manner, as one single conceptual change per PR. > > If a PR consists of dozens or hundreds of nontrivial commits, you will > want to strongly consider dividing it up into multiple PRs, as PRs of > this size simply cannot be effectively reviewed. They will either be > merged without adequate review, or outright ignored or closed. Which > one is worse, I leave to your imagination. > > 5) Pay attention and respond to review comments > > While in general it is my experience that WildFly contributors are good > about this, I'm going to quote this passage from [1] regardless: > > "Your patch will almost certainly get comments from reviewers on ways in > which the patch can be improved. You must respond to those comments; > ignoring reviewers is a good way to get ignored in return. [...] > > "Be sure to tell the reviewers what changes you are making and to thank them > for their time. Code review is a tiring and time-consuming process, and > reviewers sometimes get grumpy. Even in that case, though, respond > politely and address the problems they have pointed out." > > In addition, when something needs to be changed, the proper manner to do > so is generally to modify the original commit, not to add more commits > to the chain to fix issues as they're reported. See (4). > > 6) Don't get discouraged > > It may come to pass that you have to iterate on your pull request many > times before it is considered acceptable. Don't be discouraged by this > - instead, consider that to be a sign that the reviewers care highly > about the quality of the code base. At the same time though, consider > that it is frustrating for reviewers to have to say the same things over > and over again, so please do take care to provide as high-quality > submissions as possible, and see (5)! > > 7) You can review code too! > > You don't have to be an official reviewer in order to review a pull > request. If you see a pull request dealing with an area you are > familiar with, feel free to examine it and comment as needed. In > addition, *all* pull requests need to be reviewed for basic > (non-machine-verifiable) correctness, including noticing bad code, NPE > risks, and anti-patterns as well as "boring stuff" like spelling and > grammar and documentation. > > 8) On major refactorings > > When doing major and/or long-term refactors, while rare, it is possible > that the above constraints become impractical, especially with regard to > grouping changes. In this case, you can use a work branch on a (GitHub) > fork of WildFly, applying the above rules in micro-scale to just that > branch. In this case you could possibly ask a reviewer to also review > some or all of the pull requests to that branch. Merge commits would > then be used to periodically synchronize with upstream. > > In this way, when the long-term branch is ready to "come home" to the > main branch, the reviewers may have a good idea that the (potentially > quite numerous) changes in the work branch have been reviewed already. > > [1] https://www.kernel.org/doc/Documentation/SubmittingPatches > [2] https://developer.jboss.org/wiki/HackingOnWildFly > -- - DML From smarlow at redhat.com Fri Jul 17 20:47:26 2015 From: smarlow at redhat.com (Scott Marlow) Date: Fri, 17 Jul 2015 20:47:26 -0400 Subject: [wildfly-dev] The CI Inquisition! In-Reply-To: References: Message-ID: <55A9A21E.3030603@redhat.com> On 07/17/2015 12:26 PM, Jason Greene wrote: > Hello Everyone! > > Over the last few years we have attempted to get a grip on the intermittent test failures we see in CI almost every run, and have attempted various policies which were poorly enforced. This was mainly due to an understanding of tight deadline, but also a concern that strict enforcement would damage our test coverage. I would find myself holding out in hope that over time we would see these issues decrease. > > Unfortunately that hope was misplaced, and the simple truth is that coverage is already harmed, because no one pays attention to the intermittent fails, since they are treated as noise and not a true defect. I think we have no other option but to @Ignore any and every intermittent test, no matter the number or area they appear in. > > So unless someone can propose another workable strategy, intermittent tests should be disabled immediately by anyone that is impacted by them (reviewers, contributors, whoever). To do this, a simple short independent PR should be sent in, and a note should be left in a comment to the component lead of the area tested (using github?s super cool @user syntax). The component lead can then act on the message and choose whether to open and assign a JIRA to have it fixed, to ignore it, to delete it, to rewrite, etc. The intention is that the process of disabling an intermittent test should be as minimal effort as possible. > > In order for a known intermittent test to be reenabled, it needs to be shown that it is no longer intermittent by completing many full testsuite runs successfully. Anyone that needs it can request a custom CI job run for this purpose. > > Finally, if you are a saint and decide to fix an intermittent failing test, but have trouble reproducing it, feel free to raise the topic in the WildFly HipChat and we can come up with a solution like custom debug test jobs that can get you the info you need. > > Thoughts? It may not always be obvious but if multiple components might be impacted by ignoring the test, we should try to contact the multiple impacted parties. I only got burnt by this happening once (took me about 3 months before I noticed :-), so not really sure if its worth adding comments in test source headers about who to contact in case of intermittment failure (and subsequent @Ignore of the test) but that might help. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From tomaz.cerar at gmail.com Mon Jul 20 05:54:38 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 20 Jul 2015 11:54:38 +0200 Subject: [wildfly-dev] The CI Inquisition! In-Reply-To: References: Message-ID: I have unmuted all muted tests on CI. so if you start seeing more test failures, PR with @Ignore as Jason said should be sent. -- tomaz On Fri, Jul 17, 2015 at 6:26 PM, Jason Greene wrote: > Hello Everyone! > > Over the last few years we have attempted to get a grip on the > intermittent test failures we see in CI almost every run, and have > attempted various policies which were poorly enforced. This was mainly due > to an understanding of tight deadline, but also a concern that strict > enforcement would damage our test coverage. I would find myself holding out > in hope that over time we would see these issues decrease. > > Unfortunately that hope was misplaced, and the simple truth is that > coverage is already harmed, because no one pays attention to the > intermittent fails, since they are treated as noise and not a true defect. > I think we have no other option but to @Ignore any and every intermittent > test, no matter the number or area they appear in. > > So unless someone can propose another workable strategy, intermittent > tests should be disabled immediately by anyone that is impacted by them > (reviewers, contributors, whoever). To do this, a simple short independent > PR should be sent in, and a note should be left in a comment to the > component lead of the area tested (using github?s super cool @user syntax). > The component lead can then act on the message and choose whether to open > and assign a JIRA to have it fixed, to ignore it, to delete it, to rewrite, > etc. The intention is that the process of disabling an intermittent test > should be as minimal effort as possible. > > In order for a known intermittent test to be reenabled, it needs to be > shown that it is no longer intermittent by completing many full testsuite > runs successfully. Anyone that needs it can request a custom CI job run for > this purpose. > > Finally, if you are a saint and decide to fix an intermittent failing > test, but have trouble reproducing it, feel free to raise the topic in the > WildFly HipChat and we can come up with a solution like custom debug test > jobs that can get you the info you need. > > Thoughts? > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150720/df294761/attachment.html From brian.stansberry at redhat.com Mon Jul 20 09:32:50 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Mon, 20 Jul 2015 08:32:50 -0500 Subject: [wildfly-dev] Metrics & runtime attribute registration In-Reply-To: <55A6A5D2.8020506@redhat.com> References: <55A6A5D2.8020506@redhat.com> Message-ID: <55ACF882.9040907@redhat.com> Silence is assent. ;) So I've opened https://issues.jboss.org/browse/WFCORE-831. On 7/15/15 1:26 PM, Brian Stansberry wrote: > Based on the discussion in this thread and some related chats in > hipchat, I propose the requirements below for this general topic, and > very much welcome comments. > > Note that this thread is about metrics, but handling of non-metric > runtime-only attributes and operations all have the same concerns. > > I've placed an * next to requirements that involve some code change in > the WildFly Core kernel. If we can reach a consensus around these > requirements, that consensus can become a JIRA to implement the * items. > > I. If an Extension's initialize method is executing in a process type > where the extension CAN install runtime services, the extension MUST > register all metrics, other runtime-only attributes, and runtime-only > operations, regardless of whether the process is running in --admin-only > mode. > > II. If an Extension's initialize method is executing in a process type > where the extension CANNOT install runtime services, the extension MUST > NOT register any metrics, other runtime-only attributes, or runtime-only > operations.[1] For example, most extensions will not register these when > executing on a HostController. > > III.* The ExtensionContext.isRuntimeOnlyRegistrationValid() MUST return > the proper value to tell the extension which of conditions I and II apply. > > IV.* The AttributeDefinition class MUST expose a 'public ModelNode > getUndefinedMetricValue()' method and the builders for it MUST expose a > 'public void setUndefinedMetricValue(ModelNode value)' method. (See VI.A > below for the purpose of this.) > > A.* If assertions are enabled and an AttributeDefinition that is passed > to ManagementResourceRegistration registerReadOnlyAttribute or > registerReadWriteAttribute returns a defined ModelNode from > getUndefinedMetricValue(), an AssertionError MUST be thrown. Non-metrics > cannot provide undefined metric values. > > B.* If assertions are enabled and an AttributeDefinition that is passed > to ManagementResourceRegistration registerMetric returns a defined > ModelNode from getDefaultValue(), an AssertionError MUST be thrown. > Metrics cannot provide default values. > > C.* If assertions are enabled and an AttributeDefinition that is passed > to ManagementResourceRegistration registerMetric returns a defined > ModelNode from getUndefinedMetricValue() and also returns 'true' from > isAllowNull(), an AssertionError MUST be thrown. This is an inconsistent > setting, as the undefined metric value will ensure the client never sees > an undefined result. > > V. The read-attribute handler for a metric or runtime-only attribute > MUST set a result value consistent with the attribute description > regardless of whether the expected runtime services are disabled due to > running in --admin-only or some other configuration option such as a > 'statistics-enabled' attribute being set to 'false'. Specifically, if > the handler might not set a defined value in that situation, the > isAllowNull() method from the attribute's AttributeDefinition MUST > return 'true'. > > VI. The read-attribute handler for metrics that have a logical defined > value even if runtime services are not present SHOULD set that value as > the result when runtime services are not present. For example, for many > 'counter' metrics a value of 0 is a logical defined value. > > A. The read-attribute handler for such a metric MAY choose to not set a > result value itself when there are no runtime services, and instead > delegate to the kernel to have the kernel set the result. To configure > such a delegation, the AttributeDefinition for the metric must return a > defined value from its getUndefinedMetricValue() method. (See IV.) > > B.* The kernel's handler for read-attribute MUST check if the registered > handler for the attribute has not set a defined result. If it has not, > and the attribute is a metric, and its definition's > getUndefinedMetricValue() method returns a defined value, the kernel > handler must set that value as the result. This behavior MUST occur > regardless of the value of any 'include-defaults' parameter passed to > the hander. The 'include-defaults' parameter is unrelated to metrics. > > VII. The read-attribute handler for metrics that do not have a logical > defined value if runtime services are not present SHOULD return an > undefined result and SHOULD NOT return an arbitrary meaningless value > such as -1 or Integer.MAX_VALUE. This is not a MUST/MUST NOT requirement > because it is understood that backwards compatibility requirements may > prevent changes to some attributes, and also that some integrated > libraries may return such values without the subsystem handler's being > aware of that. > > VIII. The read-attribute handler for a custom runtime-only operation > MUST set a result value consistent with the operation description > regardless of whether the expected runtime services are disabled due to > running in --admin-only or some other configuration option. > Specifically, if the handler might not set a defined value in that > situation, the isReplyAllowNull() method from the attribute's > OperationDefinition MUST return 'true'. > > A. However, it is permissible for a custom runtime-only operation > handler to throw an OperationFailedException in this situation. The > 'runtime-only'=>true entry in the operation's descriptive metadata > provides an indication to callers that this is a possible result. > > I think that's about it. ;) > > [1] At some point in the future the restriction on runtime-only > operations may be lifted, in order to support executing the operation on > all servers in a domain. > > On 7/13/15 4:26 PM, Toma? Cerar wrote: >> Hey guys, >> >> We had interesting discussion with Brian on >> https://github.com/wildfly/wildfly-core/pull/848#issuecomment-119778986 >> about how we register runtime/metric attribute on resources. >> >> There are many cases where subsystems only register attributes / >> resources only when server is booting into normal mode. >> but if it server is booted only to "admin mode" all that runtime/metrics >> attributes are not registered and as such not seen in the model. >> >> Registering runtime attributes only in normal mode can cause that >> results of :read-resource-description/read-resource >> wouldn't return attributes that are on resources if server is started in >> admin mode or even CLI standalone. >> Our metadata already provides information if attributes is >> runtime/metric/configuration. >> >> This can cause problems for tooling that relies on output of those two >> operations. >> >> Looking at current state of the code, we do use both ways of registering >> attributes either conditionally or always. >> This probably originates from times where there was no good api/way to >> mark attribute/resource as runtime. >> >> I am personally am in favor of always registering runtime attributes as >> this makes sure that user isn't surprised by some extra/missing >> attributes based on fact how it is starting the server. >> >> >> What do you guys think? Should we always register it or have it >> conditionally? >> >> -- >> tomaz >> >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From darran.lofthouse at jboss.com Tue Jul 21 05:15:38 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 21 Jul 2015 10:15:38 +0100 Subject: [wildfly-dev] How to contribute pull requests to WildFly In-Reply-To: <55A81D38.1070009@redhat.com> References: <55A81D38.1070009@redhat.com> Message-ID: <55AE0DBA.4060206@jboss.com> On 16/07/15 22:08, David M. Lloyd wrote: > Since migrating to git, and a review-oriented contribution structure, > we've seen a massive improvement in the quality and quantity of > community contribution in both WildFly itself and its affiliated > projects. However, while we have lots of documents about how to get the > WildFly code, hack on it, use git to make a branch, submit a pull > request, etc., one thing rarely (if ever) talked about is any kind of > standards as to how to actually build and structure your pull requests, > so I'm going to establish that right now. > > I have a few reasons for doing this. First, the reviewers are stretched > thin - very thin. This has several bad effects, including (but not > limited to): > > * Pull requests sitting in the queue for extended periods of time > * Giant pull requests getting less review than small pull requests > * Pull requests receiving highly variable quality-of-review > > Secondly, we see problematic pull requests in a wide variety of shapes > and sizes, from the single-unreviewable-mega-commit PR to the > thousand-tiny-commit PR to the mixed-form-and-function-commit PR, as > well as some stealthier cases like the build-is-broken-between-commits PR. > > Thirdly, the project has reached a size and scope where we really need > to have more eyes on every change - as many as possible in fact. > > To that effect, and borrowing some concepts heavily from the Linux > Kernel project's documentation [1], I offer this. You're welcome. > > (For background on how to get started with contribution, the hacking > guide [2] is still the best place to start; after any initial > discussion, I'll probably throw this up alongside that.) > > WildFly Contribution and Pull Request Standards > ----------------------------------------------- > While a complete git tutorial is far, far out of scope of this guide, > there are a few important rules and guidelines to adhere to when > creating a pull request for WildFly or one of its constituent or related > sub-projects. > > 1) Describe the pull request adequately. > > The description *should* include a JIRA number directly from the project > in question, whose corresponding JIRA issue will in turn have been > linked to the pull request you are just now creating. The description > *should* also include a decent, human-readable summary of what is > changing. Proper spelling and grammar is a plus! In addition to that I think all commit messages should also contain both the Jira issue AND a brief description of the change. That way in a couple of years time when someone needs to use 'git annotate' the reason for the existance of a piece of code can be identified. > 2) Make sure it builds and tests pass *first*. > > It is highly annoying to reviewers when they find they've spent a great > deal of time reviewing some code only to discover that it doesn't even > compile. In particular, it's common for a patch to trip CheckStyle if > it hadn't been previously compile-tested at the least. > > While it is tempting to rely on the automated CI/GitHub integration to > do our build and test for us (and I'm guilty of having done this too), > it generally just causes trouble, so please don't do it! > > 3) Separate your changes - but not *too* much. > > This comes directly from [1], and I agree with it 100%: > > "Separate each _logical change_ into a separate patch. > > "For example, if your changes include both bug fixes and performance > enhancements for a single driver, separate those changes into two > or more patches. If your changes include an API update, and a new > driver which uses that new API, separate those into two patches. > > "On the other hand, if you make a single change to numerous files, > group those changes into a single patch. Thus a single logical change > is contained within a single patch. > > "The point to remember is that each patch should make an easily understood > change that can be verified by reviewers. Each patch should be justifiable > on its own merits. > > "If one patch depends on another patch in order for a change to be > complete, that is OK. Simply note "this patch depends on patch X" > in your patch description. > > "When dividing your change into a series of patches, take special care to > ensure that [WildFly] builds and runs properly after each patch in the > series. Developers using "git bisect" to track down a problem can end up > splitting your patch series at any point; they will not thank you if you > introduce bugs in the middle. > > "If you cannot condense your patch set into a smaller set of patches, > then only post say 15 or so at a time and wait for review and integration." > > I also want to emphasize how important it is to separate *functional* > and *non-functional* changes. The latter category includes reformatting > (which generally should *not* be done without a strong justification). > > 4) Avoid massive and/or "stream of consciousness" branches > > We all know that development can sometimes be an iterative process, and > we learn as we go. Nonetheless, we do not need or want a complete > record of all the highs and lows in the history of every change (for > example, an "add foobar" commit followed later by a "remove foobar" > commit in the same PR) - particularly for large changes or in large > projects (like WildFly proper). It is good practice for such change > authors to go back and rearrange and/or restructure the commits of a > pull request such that they incrementally introduce the change in a > logical manner, as one single conceptual change per PR. > > If a PR consists of dozens or hundreds of nontrivial commits, you will > want to strongly consider dividing it up into multiple PRs, as PRs of > this size simply cannot be effectively reviewed. They will either be > merged without adequate review, or outright ignored or closed. Which > one is worse, I leave to your imagination. > > 5) Pay attention and respond to review comments > > While in general it is my experience that WildFly contributors are good > about this, I'm going to quote this passage from [1] regardless: > > "Your patch will almost certainly get comments from reviewers on ways in > which the patch can be improved. You must respond to those comments; > ignoring reviewers is a good way to get ignored in return. [...] > > "Be sure to tell the reviewers what changes you are making and to thank them > for their time. Code review is a tiring and time-consuming process, and > reviewers sometimes get grumpy. Even in that case, though, respond > politely and address the problems they have pointed out." > > In addition, when something needs to be changed, the proper manner to do > so is generally to modify the original commit, not to add more commits > to the chain to fix issues as they're reported. See (4). > > 6) Don't get discouraged > > It may come to pass that you have to iterate on your pull request many > times before it is considered acceptable. Don't be discouraged by this > - instead, consider that to be a sign that the reviewers care highly > about the quality of the code base. At the same time though, consider > that it is frustrating for reviewers to have to say the same things over > and over again, so please do take care to provide as high-quality > submissions as possible, and see (5)! > > 7) You can review code too! > > You don't have to be an official reviewer in order to review a pull > request. If you see a pull request dealing with an area you are > familiar with, feel free to examine it and comment as needed. In > addition, *all* pull requests need to be reviewed for basic > (non-machine-verifiable) correctness, including noticing bad code, NPE > risks, and anti-patterns as well as "boring stuff" like spelling and > grammar and documentation. > > 8) On major refactorings > > When doing major and/or long-term refactors, while rare, it is possible > that the above constraints become impractical, especially with regard to > grouping changes. In this case, you can use a work branch on a (GitHub) > fork of WildFly, applying the above rules in micro-scale to just that > branch. In this case you could possibly ask a reviewer to also review > some or all of the pull requests to that branch. Merge commits would > then be used to periodically synchronize with upstream. > > In this way, when the long-term branch is ready to "come home" to the > main branch, the reviewers may have a good idea that the (potentially > quite numerous) changes in the work branch have been reviewed already. > > [1] https://www.kernel.org/doc/Documentation/SubmittingPatches > [2] https://developer.jboss.org/wiki/HackingOnWildFly > From darran.lofthouse at jboss.com Tue Jul 21 07:48:01 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Tue, 21 Jul 2015 12:48:01 +0100 Subject: [wildfly-dev] How to contribute pull requests to WildFly In-Reply-To: <55A81D38.1070009@redhat.com> References: <55A81D38.1070009@redhat.com> Message-ID: <55AE3171.3050102@jboss.com> On 16/07/15 22:08, David M. Lloyd wrote: > Since migrating to git, and a review-oriented contribution structure, > we've seen a massive improvement in the quality and quantity of > community contribution in both WildFly itself and its affiliated > projects. However, while we have lots of documents about how to get the > WildFly code, hack on it, use git to make a branch, submit a pull > request, etc., one thing rarely (if ever) talked about is any kind of > standards as to how to actually build and structure your pull requests, > so I'm going to establish that right now. > > I have a few reasons for doing this. First, the reviewers are stretched > thin - very thin. This has several bad effects, including (but not > limited to): > > * Pull requests sitting in the queue for extended periods of time > * Giant pull requests getting less review than small pull requests > * Pull requests receiving highly variable quality-of-review > > Secondly, we see problematic pull requests in a wide variety of shapes > and sizes, from the single-unreviewable-mega-commit PR to the > thousand-tiny-commit PR to the mixed-form-and-function-commit PR, as > well as some stealthier cases like the build-is-broken-between-commits PR. > > Thirdly, the project has reached a size and scope where we really need > to have more eyes on every change - as many as possible in fact. > > To that effect, and borrowing some concepts heavily from the Linux > Kernel project's documentation [1], I offer this. You're welcome. > > (For background on how to get started with contribution, the hacking > guide [2] is still the best place to start; after any initial > discussion, I'll probably throw this up alongside that.) > > WildFly Contribution and Pull Request Standards > ----------------------------------------------- > While a complete git tutorial is far, far out of scope of this guide, > there are a few important rules and guidelines to adhere to when > creating a pull request for WildFly or one of its constituent or related > sub-projects. > > 1) Describe the pull request adequately. > > The description *should* include a JIRA number directly from the project > in question, whose corresponding JIRA issue will in turn have been > linked to the pull request you are just now creating. The description > *should* also include a decent, human-readable summary of what is > changing. Proper spelling and grammar is a plus! > > 2) Make sure it builds and tests pass *first*. > > It is highly annoying to reviewers when they find they've spent a great > deal of time reviewing some code only to discover that it doesn't even > compile. In particular, it's common for a patch to trip CheckStyle if > it hadn't been previously compile-tested at the least. > > While it is tempting to rely on the automated CI/GitHub integration to > do our build and test for us (and I'm guilty of having done this too), > it generally just causes trouble, so please don't do it! On this point, running the build with the subset of tests locally is fine, attempting to do a full test run however is just too painful. I have a PR in the queue that has a failed test due to my changes, trying to run that portion of the testsuite locally I am now debugging why a completely different test has failed. > 3) Separate your changes - but not *too* much. > > This comes directly from [1], and I agree with it 100%: > > "Separate each _logical change_ into a separate patch. > > "For example, if your changes include both bug fixes and performance > enhancements for a single driver, separate those changes into two > or more patches. If your changes include an API update, and a new > driver which uses that new API, separate those into two patches. > > "On the other hand, if you make a single change to numerous files, > group those changes into a single patch. Thus a single logical change > is contained within a single patch. > > "The point to remember is that each patch should make an easily understood > change that can be verified by reviewers. Each patch should be justifiable > on its own merits. > > "If one patch depends on another patch in order for a change to be > complete, that is OK. Simply note "this patch depends on patch X" > in your patch description. > > "When dividing your change into a series of patches, take special care to > ensure that [WildFly] builds and runs properly after each patch in the > series. Developers using "git bisect" to track down a problem can end up > splitting your patch series at any point; they will not thank you if you > introduce bugs in the middle. > > "If you cannot condense your patch set into a smaller set of patches, > then only post say 15 or so at a time and wait for review and integration." > > I also want to emphasize how important it is to separate *functional* > and *non-functional* changes. The latter category includes reformatting > (which generally should *not* be done without a strong justification). > > 4) Avoid massive and/or "stream of consciousness" branches > > We all know that development can sometimes be an iterative process, and > we learn as we go. Nonetheless, we do not need or want a complete > record of all the highs and lows in the history of every change (for > example, an "add foobar" commit followed later by a "remove foobar" > commit in the same PR) - particularly for large changes or in large > projects (like WildFly proper). It is good practice for such change > authors to go back and rearrange and/or restructure the commits of a > pull request such that they incrementally introduce the change in a > logical manner, as one single conceptual change per PR. > > If a PR consists of dozens or hundreds of nontrivial commits, you will > want to strongly consider dividing it up into multiple PRs, as PRs of > this size simply cannot be effectively reviewed. They will either be > merged without adequate review, or outright ignored or closed. Which > one is worse, I leave to your imagination. > > 5) Pay attention and respond to review comments > > While in general it is my experience that WildFly contributors are good > about this, I'm going to quote this passage from [1] regardless: > > "Your patch will almost certainly get comments from reviewers on ways in > which the patch can be improved. You must respond to those comments; > ignoring reviewers is a good way to get ignored in return. [...] > > "Be sure to tell the reviewers what changes you are making and to thank them > for their time. Code review is a tiring and time-consuming process, and > reviewers sometimes get grumpy. Even in that case, though, respond > politely and address the problems they have pointed out." > > In addition, when something needs to be changed, the proper manner to do > so is generally to modify the original commit, not to add more commits > to the chain to fix issues as they're reported. See (4). > > 6) Don't get discouraged > > It may come to pass that you have to iterate on your pull request many > times before it is considered acceptable. Don't be discouraged by this > - instead, consider that to be a sign that the reviewers care highly > about the quality of the code base. At the same time though, consider > that it is frustrating for reviewers to have to say the same things over > and over again, so please do take care to provide as high-quality > submissions as possible, and see (5)! > > 7) You can review code too! > > You don't have to be an official reviewer in order to review a pull > request. If you see a pull request dealing with an area you are > familiar with, feel free to examine it and comment as needed. In > addition, *all* pull requests need to be reviewed for basic > (non-machine-verifiable) correctness, including noticing bad code, NPE > risks, and anti-patterns as well as "boring stuff" like spelling and > grammar and documentation. > > 8) On major refactorings > > When doing major and/or long-term refactors, while rare, it is possible > that the above constraints become impractical, especially with regard to > grouping changes. In this case, you can use a work branch on a (GitHub) > fork of WildFly, applying the above rules in micro-scale to just that > branch. In this case you could possibly ask a reviewer to also review > some or all of the pull requests to that branch. Merge commits would > then be used to periodically synchronize with upstream. > > In this way, when the long-term branch is ready to "come home" to the > main branch, the reviewers may have a good idea that the (potentially > quite numerous) changes in the work branch have been reviewed already. > > [1] https://www.kernel.org/doc/Documentation/SubmittingPatches > [2] https://developer.jboss.org/wiki/HackingOnWildFly > From sstark at redhat.com Tue Jul 21 13:58:08 2015 From: sstark at redhat.com (Scott Stark) Date: Tue, 21 Jul 2015 13:58:08 -0400 (EDT) Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. In-Reply-To: <412962493.1836423.1437500660957.JavaMail.zimbra@redhat.com> Message-ID: <172349015.1843388.1437501488613.JavaMail.zimbra@redhat.com> In case you didn't see the msg I sent to the core, I started up a discussion thread "What are our middleware sun.misc.Unsafe uses?" (https://developer.jboss.org/message/936359) to identify and track the replacement for all of the Unsafe uses. As the start of the discussion indicates, this came up because there was fear that Java 9 would prevent access to the various internal packages. There may be a Java EC working group on the problem, but it would be best for use to work on getting public replacements in place by working with our OpenJDK team lead by Andrew Haley. I have some comments I collected from other threads on the topic from Andrew, Jason and David as well as the Java EC summary of the Unsafe situation as background at the start of the thread. Please add to or correct anything that shows up on the thread as I work through the projects to identify what we are using and why. The first think I checked out was the use of the Unsafe usage by jboss-modules in the current wildfly trunk build. That turns out to be synchronization primitives that have already been dropped in the 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these are similar workarounds for older Java platforms, but where they are not, I want to make sure we are either tracking or creating an OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api replacement. From eduardo.santanadasilva at gmail.com Tue Jul 21 15:04:58 2015 From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva) Date: Tue, 21 Jul 2015 16:04:58 -0300 Subject: [wildfly-dev] DOS causes logs with huge size Message-ID: Anyone already saw this? I had, what I presume was a DOS attack in a virtual machine on the cloud, that consumes all space left. I saw single files log with more than 2.5G of information on my standalone log directory: 2015-07-20 06:53:46,024 SEVERE [javax.jmdns.impl.constants.DNSRecordType] (SocketListener(45-55-77-19.local.)) Could not find reco rd type for index: -1 2015-07-20 06:53:46,042 SEVERE [javax.jmdns.impl.DNSIncoming] (SocketListener(45-55-77-19.local.)) Could not find record type: dns [query,192.99.0.161:52050, length=184, id=0x5c78, flags=0x3030] 0: 5c7830305c783030 5c7830305c783030 5c7830305c783031 5c7830305c783030 \x00\x00 \x00\x00 \x00\x01 \x00\x00 20: 5c7830305c783030 5c7830305c783030 5c7830395c783546 5c7837335c783635 \x00\x00 \x00\x00 \x09\x5F \x73\x65 40: 5c7837325c783736 5c7836395c783633 5c7836355c783733 5c7830375c783546 \x72\x76 \x69\x63 \x65\x73 \x07\x5F 60: 5c7836345c783645 5c7837335c783244 5c7837335c783634 5c7830345c783546 \x64\x6E \x73\x2D \x73\x64 \x04\x5F 80: 5c7837355c783634 5c7837305c783035 5c7836435c783646 5c7836335c783631 \x75\x64 \x70\x05 \x6C\x6F \x63\x61 a0: 5c7836435c783030 5c7830305c783043 5c7830305c783031 \x6C\x00 \x00\x0C \x00\x01 2015-07-20 06:53:46,076 WARNING [javax.jmdns.impl.constants.DNSRecordClass] (SocketListener(45-55-77-19.local.)) Could not find re cord class for index: -1 2015-07-20 06:53:46,260 SEVERE [javax.jmdns.impl.DNSIncoming$MessageInputStream] (SocketListener(45-55-77-19.local.)) bad domain n ame: possible circular name detected. Bad offset: 0xffffffff at 0xb6 2015-07-20 06:53:46,270 SEVERE [javax.jmdns.impl.constants.DNSRecordType] (SocketListener(45-55-77-19.local.)) Could not find reco rd type for index: -1 2015-07-20 06:53:46,296 SEVERE [javax.jmdns.impl.DNSIncoming] (SocketListener(45-55-77-19.local.)) Could not find record type: dns [query,192.99.0.161:52050, length=184, id=0x5c78, flags=0x3030, questions=1 questions: [DNSQuestion at 2024648779 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: 0\x00\x01\x00\x00\x00\x00\x00\x00\x 09\x5F\x73\x6.\x72\x76\x69\x63\x65\x73\x07\x5F\x64\x6E\x73\x2D\x73\.4\x04\x5F\x75\x64\x70\x05\x6C\x6F\x63\x61\x6C\x00\x00\.C\x00\x 01????????????????????.]] question: [DNSQuestion at 2024648779 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: 0\x00\x01\x00\x00\x0 0\x00\x00\x00\x09\x5F\x73\x6.\x72\x76\x69\x63\x65\x73\x07\x5F\x64\x6E\x73\x2D\x73\.4\x04\x5F\x75\x64\x70\x05\x6C\x6F\x63\x61\x6C\x 00\x00\.C\x00\x01????????????????????.] 0: 5c7830305c783030 5c7830305c783030 5c7830305c783031 5c7830305c783030 \x00\x00 \x00\x00 \x00\x01 \x00\x00 20: 5c7830305c783030 5c7830305c783030 5c7830395c783546 5c7837335c783635 \x00\x00 \x00\x00 \x09\x5F \x73\x65 40: 5c7837325c783736 5c7836395c783633 5c7836355c783733 5c7830375c783546 \x72\x76 \x69\x63 \x65\x73 \x07\x5F 60: 5c7836345c783645 5c7837335c783244 5c7837335c783634 5c7830345c783546 \x64\x6E \x73\x2D \x73\x64 \x04\x5F 80: 5c7837355c783634 5c7837305c783035 5c7836435c783646 5c7836335c783631 \x75\x64 \x70\x05 \x6C\x6F \x63\x61 a0: 5c7836435c783030 5c7830305c783043 5c7830305c783031 \x6C\x00 \x00\x0C \x00\x01 Maybe this could give a hint: http://sourceforge.net/p/jmdns/bugs/130/ Is this an issue that wildfly should care about? Regards Eduardo Sant'Ana da Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150721/9752da15/attachment.html From jason.greene at redhat.com Tue Jul 21 15:09:20 2015 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 21 Jul 2015 14:09:20 -0500 Subject: [wildfly-dev] DOS causes logs with huge size In-Reply-To: References: Message-ID: Did you try filtering out all of those log categories? > On Jul 21, 2015, at 2:04 PM, Eduardo Sant'Ana da Silva wrote: > > Anyone already saw this? > > I had, what I presume was a DOS attack in a virtual machine on the cloud, that consumes all space left. > > I saw single files log with more than 2.5G of information on my standalone log directory: > > 2015-07-20 06:53:46,024 SEVERE [javax.jmdns.impl.constants.DNSRecordType] (SocketListener(45-55-77-19.local.)) Could not find reco > rd type for index: -1 > 2015-07-20 06:53:46,042 SEVERE [javax.jmdns.impl.DNSIncoming] (SocketListener(45-55-77-19.local.)) Could not find record type: dns > [query,192.99.0.161:52050, length=184, id=0x5c78, flags=0x3030] > 0: 5c7830305c783030 5c7830305c783030 5c7830305c783031 5c7830305c783030 \x00\x00 \x00\x00 \x00\x01 \x00\x00 > 20: 5c7830305c783030 5c7830305c783030 5c7830395c783546 5c7837335c783635 \x00\x00 \x00\x00 \x09\x5F \x73\x65 > 40: 5c7837325c783736 5c7836395c783633 5c7836355c783733 5c7830375c783546 \x72\x76 \x69\x63 \x65\x73 \x07\x5F > 60: 5c7836345c783645 5c7837335c783244 5c7837335c783634 5c7830345c783546 \x64\x6E \x73\x2D \x73\x64 \x04\x5F > 80: 5c7837355c783634 5c7837305c783035 5c7836435c783646 5c7836335c783631 \x75\x64 \x70\x05 \x6C\x6F \x63\x61 > a0: 5c7836435c783030 5c7830305c783043 5c7830305c783031 \x6C\x00 \x00\x0C \x00\x01 > > 2015-07-20 06:53:46,076 WARNING [javax.jmdns.impl.constants.DNSRecordClass] (SocketListener(45-55-77-19.local.)) Could not find re > cord class for index: -1 > 2015-07-20 06:53:46,260 SEVERE [javax.jmdns.impl.DNSIncoming$MessageInputStream] (SocketListener(45-55-77-19.local.)) bad domain n > ame: possible circular name detected. Bad offset: 0xffffffff at 0xb6 > 2015-07-20 06:53:46,270 SEVERE [javax.jmdns.impl.constants.DNSRecordType] (SocketListener(45-55-77-19.local.)) Could not find reco > rd type for index: -1 > 2015-07-20 06:53:46,296 SEVERE [javax.jmdns.impl.DNSIncoming] (SocketListener(45-55-77-19.local.)) Could not find record type: dns > [query,192.99.0.161:52050, length=184, id=0x5c78, flags=0x3030, questions=1 > questions: > [DNSQuestion at 2024648779 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: 0\x00\x01\x00\x00\x00\x00\x00\x00\x > 09\x5F\x73\x6.\x72\x76\x69\x63\x65\x73\x07\x5F\x64\x6E\x73\x2D\x73\.4\x04\x5F\x75\x64\x70\x05\x6C\x6F\x63\x61\x6C\x00\x00\.C\x00\x > 01????????????????????.]] > question: [DNSQuestion at 2024648779 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: 0\x00\x01\x00\x00\x0 > 0\x00\x00\x00\x09\x5F\x73\x6.\x72\x76\x69\x63\x65\x73\x07\x5F\x64\x6E\x73\x2D\x73\.4\x04\x5F\x75\x64\x70\x05\x6C\x6F\x63\x61\x6C\x > 00\x00\.C\x00\x01????????????????????.] > 0: 5c7830305c783030 5c7830305c783030 5c7830305c783031 5c7830305c783030 \x00\x00 \x00\x00 \x00\x01 \x00\x00 > 20: 5c7830305c783030 5c7830305c783030 5c7830395c783546 5c7837335c783635 \x00\x00 \x00\x00 \x09\x5F \x73\x65 > 40: 5c7837325c783736 5c7836395c783633 5c7836355c783733 5c7830375c783546 \x72\x76 \x69\x63 \x65\x73 \x07\x5F > 60: 5c7836345c783645 5c7837335c783244 5c7837335c783634 5c7830345c783546 \x64\x6E \x73\x2D \x73\x64 \x04\x5F > 80: 5c7837355c783634 5c7837305c783035 5c7836435c783646 5c7836335c783631 \x75\x64 \x70\x05 \x6C\x6F \x63\x61 > a0: 5c7836435c783030 5c7830305c783043 5c7830305c783031 \x6C\x00 \x00\x0C \x00\x01 > > > > Maybe this could give a hint: > > http://sourceforge.net/p/jmdns/bugs/130/ > > Is this an issue that wildfly should care about? > > Regards > Eduardo Sant'Ana da Silva > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150721/d6fdecb1/attachment-0001.html From eduardo.santanadasilva at gmail.com Tue Jul 21 15:10:30 2015 From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva) Date: Tue, 21 Jul 2015 16:10:30 -0300 Subject: [wildfly-dev] DOS causes logs with huge size In-Reply-To: References: Message-ID: No, how can I do this? On Jul 21, 2015, at 4:09 PM, Jason Greene wrote: > Did you try filtering out all of those log categories? > >> On Jul 21, 2015, at 2:04 PM, Eduardo Sant'Ana da Silva wrote: >> >> Anyone already saw this? >> >> I had, what I presume was a DOS attack in a virtual machine on the cloud, that consumes all space left. >> >> I saw single files log with more than 2.5G of information on my standalone log directory: >> >> 2015-07-20 06:53:46,024 SEVERE [javax.jmdns.impl.constants.DNSRecordType] (SocketListener(45-55-77-19.local.)) Could not find reco >> rd type for index: -1 >> 2015-07-20 06:53:46,042 SEVERE [javax.jmdns.impl.DNSIncoming] (SocketListener(45-55-77-19.local.)) Could not find record type: dns >> [query,192.99.0.161:52050, length=184, id=0x5c78, flags=0x3030] >> 0: 5c7830305c783030 5c7830305c783030 5c7830305c783031 5c7830305c783030 \x00\x00 \x00\x00 \x00\x01 \x00\x00 >> 20: 5c7830305c783030 5c7830305c783030 5c7830395c783546 5c7837335c783635 \x00\x00 \x00\x00 \x09\x5F \x73\x65 >> 40: 5c7837325c783736 5c7836395c783633 5c7836355c783733 5c7830375c783546 \x72\x76 \x69\x63 \x65\x73 \x07\x5F >> 60: 5c7836345c783645 5c7837335c783244 5c7837335c783634 5c7830345c783546 \x64\x6E \x73\x2D \x73\x64 \x04\x5F >> 80: 5c7837355c783634 5c7837305c783035 5c7836435c783646 5c7836335c783631 \x75\x64 \x70\x05 \x6C\x6F \x63\x61 >> a0: 5c7836435c783030 5c7830305c783043 5c7830305c783031 \x6C\x00 \x00\x0C \x00\x01 >> >> 2015-07-20 06:53:46,076 WARNING [javax.jmdns.impl.constants.DNSRecordClass] (SocketListener(45-55-77-19.local.)) Could not find re >> cord class for index: -1 >> 2015-07-20 06:53:46,260 SEVERE [javax.jmdns.impl.DNSIncoming$MessageInputStream] (SocketListener(45-55-77-19.local.)) bad domain n >> ame: possible circular name detected. Bad offset: 0xffffffff at 0xb6 >> 2015-07-20 06:53:46,270 SEVERE [javax.jmdns.impl.constants.DNSRecordType] (SocketListener(45-55-77-19.local.)) Could not find reco >> rd type for index: -1 >> 2015-07-20 06:53:46,296 SEVERE [javax.jmdns.impl.DNSIncoming] (SocketListener(45-55-77-19.local.)) Could not find record type: dns >> [query,192.99.0.161:52050, length=184, id=0x5c78, flags=0x3030, questions=1 >> questions: >> [DNSQuestion at 2024648779 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: 0\x00\x01\x00\x00\x00\x00\x00\x00\x >> 09\x5F\x73\x6.\x72\x76\x69\x63\x65\x73\x07\x5F\x64\x6E\x73\x2D\x73\.4\x04\x5F\x75\x64\x70\x05\x6C\x6F\x63\x61\x6C\x00\x00\.C\x00\x >> 01????????????????????.]] >> question: [DNSQuestion at 2024648779 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: 0\x00\x01\x00\x00\x0 >> 0\x00\x00\x00\x09\x5F\x73\x6.\x72\x76\x69\x63\x65\x73\x07\x5F\x64\x6E\x73\x2D\x73\.4\x04\x5F\x75\x64\x70\x05\x6C\x6F\x63\x61\x6C\x >> 00\x00\.C\x00\x01????????????????????.] >> 0: 5c7830305c783030 5c7830305c783030 5c7830305c783031 5c7830305c783030 \x00\x00 \x00\x00 \x00\x01 \x00\x00 >> 20: 5c7830305c783030 5c7830305c783030 5c7830395c783546 5c7837335c783635 \x00\x00 \x00\x00 \x09\x5F \x73\x65 >> 40: 5c7837325c783736 5c7836395c783633 5c7836355c783733 5c7830375c783546 \x72\x76 \x69\x63 \x65\x73 \x07\x5F >> 60: 5c7836345c783645 5c7837335c783244 5c7837335c783634 5c7830345c783546 \x64\x6E \x73\x2D \x73\x64 \x04\x5F >> 80: 5c7837355c783634 5c7837305c783035 5c7836435c783646 5c7836335c783631 \x75\x64 \x70\x05 \x6C\x6F \x63\x61 >> a0: 5c7836435c783030 5c7830305c783043 5c7830305c783031 \x6C\x00 \x00\x0C \x00\x01 >> >> >> >> Maybe this could give a hint: >> >> http://sourceforge.net/p/jmdns/bugs/130/ >> >> Is this an issue that wildfly should care about? >> >> Regards >> Eduardo Sant'Ana da Silva >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150721/9446fdea/attachment.html From jason.greene at redhat.com Tue Jul 21 15:44:46 2015 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 21 Jul 2015 14:44:46 -0500 Subject: [wildfly-dev] DOS causes logs with huge size In-Reply-To: References: Message-ID: In the CLI do: /subsystem=logging/logger=javax.jmdns:add /subsystem=logging/logger=javax.jmdns:write-attribute(name=level,value=OFF) Or you can edit the XML and add: > On Jul 21, 2015, at 2:10 PM, Eduardo Sant'Ana da Silva wrote: > > No, how can I do this? > > On Jul 21, 2015, at 4:09 PM, Jason Greene > wrote: > >> Did you try filtering out all of those log categories? >> >>> On Jul 21, 2015, at 2:04 PM, Eduardo Sant'Ana da Silva > wrote: >>> >>> Anyone already saw this? >>> >>> I had, what I presume was a DOS attack in a virtual machine on the cloud, that consumes all space left. >>> >>> I saw single files log with more than 2.5G of information on my standalone log directory: >>> >>> 2015-07-20 06:53:46,024 SEVERE [javax.jmdns.impl.constants.DNSRecordType] (SocketListener(45-55-77-19.local.)) Could not find reco >>> rd type for index: -1 >>> 2015-07-20 06:53:46,042 SEVERE [javax.jmdns.impl.DNSIncoming] (SocketListener(45-55-77-19.local.)) Could not find record type: dns >>> [query,192.99.0.161:52050, length=184, id=0x5c78, flags=0x3030] >>> 0: 5c7830305c783030 5c7830305c783030 5c7830305c783031 5c7830305c783030 \x00\x00 \x00\x00 \x00\x01 \x00\x00 >>> 20: 5c7830305c783030 5c7830305c783030 5c7830395c783546 5c7837335c783635 \x00\x00 \x00\x00 \x09\x5F \x73\x65 >>> 40: 5c7837325c783736 5c7836395c783633 5c7836355c783733 5c7830375c783546 \x72\x76 \x69\x63 \x65\x73 \x07\x5F >>> 60: 5c7836345c783645 5c7837335c783244 5c7837335c783634 5c7830345c783546 \x64\x6E \x73\x2D \x73\x64 \x04\x5F >>> 80: 5c7837355c783634 5c7837305c783035 5c7836435c783646 5c7836335c783631 \x75\x64 \x70\x05 \x6C\x6F \x63\x61 >>> a0: 5c7836435c783030 5c7830305c783043 5c7830305c783031 \x6C\x00 \x00\x0C \x00\x01 >>> >>> 2015-07-20 06:53:46,076 WARNING [javax.jmdns.impl.constants.DNSRecordClass] (SocketListener(45-55-77-19.local.)) Could not find re >>> cord class for index: -1 >>> 2015-07-20 06:53:46,260 SEVERE [javax.jmdns.impl.DNSIncoming$MessageInputStream] (SocketListener(45-55-77-19.local.)) bad domain n >>> ame: possible circular name detected. Bad offset: 0xffffffff at 0xb6 >>> 2015-07-20 06:53:46,270 SEVERE [javax.jmdns.impl.constants.DNSRecordType] (SocketListener(45-55-77-19.local.)) Could not find reco >>> rd type for index: -1 >>> 2015-07-20 06:53:46,296 SEVERE [javax.jmdns.impl.DNSIncoming] (SocketListener(45-55-77-19.local.)) Could not find record type: dns >>> [query,192.99.0.161:52050, length=184, id=0x5c78, flags=0x3030, questions=1 >>> questions: >>> [DNSQuestion at 2024648779 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: 0\x00\x01\x00\x00\x00\x00\x00\x00\x >>> 09\x5F\x73\x6.\x72\x76\x69\x63\x65\x73\x07\x5F\x64\x6E\x73\x2D\x73\.4\x04\x5F\x75\x64\x70\x05\x6C\x6F\x63\x61\x6C\x00\x00\.C\x00\x >>> 01????????????????????.]] >>> question: [DNSQuestion at 2024648779 type: TYPE_IGNORE index 0, class: CLASS_UNKNOWN index 0, name: 0\x00\x01\x00\x00\x0 >>> 0\x00\x00\x00\x09\x5F\x73\x6.\x72\x76\x69\x63\x65\x73\x07\x5F\x64\x6E\x73\x2D\x73\.4\x04\x5F\x75\x64\x70\x05\x6C\x6F\x63\x61\x6C\x >>> 00\x00\.C\x00\x01????????????????????.] >>> 0: 5c7830305c783030 5c7830305c783030 5c7830305c783031 5c7830305c783030 \x00\x00 \x00\x00 \x00\x01 \x00\x00 >>> 20: 5c7830305c783030 5c7830305c783030 5c7830395c783546 5c7837335c783635 \x00\x00 \x00\x00 \x09\x5F \x73\x65 >>> 40: 5c7837325c783736 5c7836395c783633 5c7836355c783733 5c7830375c783546 \x72\x76 \x69\x63 \x65\x73 \x07\x5F >>> 60: 5c7836345c783645 5c7837335c783244 5c7837335c783634 5c7830345c783546 \x64\x6E \x73\x2D \x73\x64 \x04\x5F >>> 80: 5c7837355c783634 5c7837305c783035 5c7836435c783646 5c7836335c783631 \x75\x64 \x70\x05 \x6C\x6F \x63\x61 >>> a0: 5c7836435c783030 5c7830305c783043 5c7830305c783031 \x6C\x00 \x00\x0C \x00\x01 >>> >>> >>> >>> Maybe this could give a hint: >>> >>> http://sourceforge.net/p/jmdns/bugs/130/ >>> >>> Is this an issue that wildfly should care about? >>> >>> Regards >>> Eduardo Sant'Ana da Silva >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150721/0b647b84/attachment-0001.html From sstark at redhat.com Tue Jul 21 16:44:26 2015 From: sstark at redhat.com (Scott Stark) Date: Tue, 21 Jul 2015 16:44:26 -0400 (EDT) Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. In-Reply-To: <172349015.1843388.1437501488613.JavaMail.zimbra@redhat.com> References: <172349015.1843388.1437501488613.JavaMail.zimbra@redhat.com> Message-ID: <483824663.1938782.1437511466370.JavaMail.zimbra@redhat.com> One major usage jumping out is that of JSR166 java.util.concurrency class backports. These will be a non-issue once Java 8+ is a requirement. ----- Original Message ----- From: "Scott Stark" To: wildfly-dev at lists.jboss.org Sent: Tuesday, July 21, 2015 10:58:08 AM Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. In case you didn't see the msg I sent to the core, I started up a discussion thread "What are our middleware sun.misc.Unsafe uses?" (https://developer.jboss.org/message/936359) to identify and track the replacement for all of the Unsafe uses. As the start of the discussion indicates, this came up because there was fear that Java 9 would prevent access to the various internal packages. There may be a Java EC working group on the problem, but it would be best for use to work on getting public replacements in place by working with our OpenJDK team lead by Andrew Haley. I have some comments I collected from other threads on the topic from Andrew, Jason and David as well as the Java EC summary of the Unsafe situation as background at the start of the thread. Please add to or correct anything that shows up on the thread as I work through the projects to identify what we are using and why. The first think I checked out was the use of the Unsafe usage by jboss-modules in the current wildfly trunk build. That turns out to be synchronization primitives that have already been dropped in the 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these are similar workarounds for older Java platforms, but where they are not, I want to make sure we are either tracking or creating an OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api replacement. _______________________________________________ wildfly-dev mailing list wildfly-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev From jason.greene at redhat.com Tue Jul 21 17:01:45 2015 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 21 Jul 2015 16:01:45 -0500 Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. In-Reply-To: <483824663.1938782.1437511466370.JavaMail.zimbra@redhat.com> References: <172349015.1843388.1437501488613.JavaMail.zimbra@redhat.com> <483824663.1938782.1437511466370.JavaMail.zimbra@redhat.com> Message-ID: <6A132405-4315-45BF-BF9E-1C17A1FAD2F2@redhat.com> Right, it effectively locks us out of creating either derivatives or backports of java.util.concurrent, which is an active project that moves along independently of the JDK, leaving it continually behind. So its still a problem after JDK8. There are ways around it, in that you can port them in many cases to using AtomicXXX or AtomicXXXReferenceFieldUpdater. However, these are currently slower. > On Jul 21, 2015, at 3:44 PM, Scott Stark wrote: > > One major usage jumping out is that of JSR166 java.util.concurrency class backports. These will be a non-issue once Java 8+ is a requirement. > > ----- Original Message ----- > From: "Scott Stark" > To: wildfly-dev at lists.jboss.org > Sent: Tuesday, July 21, 2015 10:58:08 AM > Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. > > In case you didn't see the msg I sent to the core, I started up a discussion thread "What are our middleware sun.misc.Unsafe uses?" (https://developer.jboss.org/message/936359) to identify and track the replacement for all of the Unsafe uses. As the start of the discussion indicates, this came up because there was fear that Java 9 would prevent access to the various internal packages. There may be a Java EC working group on the problem, but it would be best for use to work on getting public replacements in place by working with our OpenJDK team lead by Andrew Haley. > > I have some comments I collected from other threads on the topic from Andrew, Jason and David as well as the Java EC summary of the Unsafe situation as background at the start of the thread. > > Please add to or correct anything that shows up on the thread as I work through the projects to identify what we are using and why. > > The first think I checked out was the use of the Unsafe usage by jboss-modules in the current wildfly trunk build. That turns out to be synchronization primitives that have already been dropped in the 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these are similar workarounds for older Java platforms, but where they are not, I want to make sure we are either tracking or creating an OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api replacement. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From tomaz.cerar at gmail.com Wed Jul 22 08:35:05 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 22 Jul 2015 14:35:05 +0200 Subject: [wildfly-dev] Removing wildfly embedded Message-ID: Hi folks, I was wondering if we could remove wildfly-embedded (GAV: org.wildfly:wildfly-embedded) https://github.com/wildfly/wildfly/tree/master/embedded module given that we now have better embedded in WildFly-core (GAV: org.wildfly.core:wildfly-embedded) https://github.com/wildfly/wildfly-core/tree/master/embedded Only user we had (that I know of) was WildFly arquillian adapter but that was moved to wildfly-core's embedded already. So any objections to removing embedded from WldFly full codebase? any potential users should migrate can easily migrate to new API if they desire. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150722/2e2b381a/attachment.html From sstark at redhat.com Wed Jul 22 12:27:15 2015 From: sstark at redhat.com (Scott Stark) Date: Wed, 22 Jul 2015 12:27:15 -0400 (EDT) Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. In-Reply-To: <6A132405-4315-45BF-BF9E-1C17A1FAD2F2@redhat.com> References: <172349015.1843388.1437501488613.JavaMail.zimbra@redhat.com> <483824663.1938782.1437511466370.JavaMail.zimbra@redhat.com> <6A132405-4315-45BF-BF9E-1C17A1FAD2F2@redhat.com> Message-ID: <1934704869.2345817.1437582435109.JavaMail.zimbra@redhat.com> Your talking about why we need to still have a push for the features of Unsafe to be exposed in the jdk to allow for innovation? Agreed about that. ----- Original Message ----- From: "Jason Greene" To: "Scott Stark" Cc: wildfly-dev at lists.jboss.org Sent: Tuesday, July 21, 2015 2:01:45 PM Subject: Re: [wildfly-dev] sun.misc.Unsafe usage, etc. Right, it effectively locks us out of creating either derivatives or backports of java.util.concurrent, which is an active project that moves along independently of the JDK, leaving it continually behind. So its still a problem after JDK8. There are ways around it, in that you can port them in many cases to using AtomicXXX or AtomicXXXReferenceFieldUpdater. However, these are currently slower. > On Jul 21, 2015, at 3:44 PM, Scott Stark wrote: > > One major usage jumping out is that of JSR166 java.util.concurrency class backports. These will be a non-issue once Java 8+ is a requirement. > > ----- Original Message ----- > From: "Scott Stark" > To: wildfly-dev at lists.jboss.org > Sent: Tuesday, July 21, 2015 10:58:08 AM > Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. > > In case you didn't see the msg I sent to the core, I started up a discussion thread "What are our middleware sun.misc.Unsafe uses?" (https://developer.jboss.org/message/936359) to identify and track the replacement for all of the Unsafe uses. As the start of the discussion indicates, this came up because there was fear that Java 9 would prevent access to the various internal packages. There may be a Java EC working group on the problem, but it would be best for use to work on getting public replacements in place by working with our OpenJDK team lead by Andrew Haley. > > I have some comments I collected from other threads on the topic from Andrew, Jason and David as well as the Java EC summary of the Unsafe situation as background at the start of the thread. > > Please add to or correct anything that shows up on the thread as I work through the projects to identify what we are using and why. > > The first think I checked out was the use of the Unsafe usage by jboss-modules in the current wildfly trunk build. That turns out to be synchronization primitives that have already been dropped in the 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these are similar workarounds for older Java platforms, but where they are not, I want to make sure we are either tracking or creating an OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api replacement. > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Wed Jul 22 13:15:27 2015 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 22 Jul 2015 12:15:27 -0500 Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. In-Reply-To: <1934704869.2345817.1437582435109.JavaMail.zimbra@redhat.com> References: <172349015.1843388.1437501488613.JavaMail.zimbra@redhat.com> <483824663.1938782.1437511466370.JavaMail.zimbra@redhat.com> <6A132405-4315-45BF-BF9E-1C17A1FAD2F2@redhat.com> <1934704869.2345817.1437582435109.JavaMail.zimbra@redhat.com> Message-ID: <8BFD699F-0DA0-48A1-80A9-9DE723156ED6@redhat.com> Yes thats exactly what I mean. These low level hooks have been a boon to innovation, and it would be a shame to stifle that. I am sympathetic to their desire to not provide compatibility guarantees around these methods, and to hide them by default. So if they go the route of a flag or a special module import/permission I think thats reasonable and accomplishes that goal. I am more worried about them being outright prevented and unreachable. > On Jul 22, 2015, at 11:27 AM, Scott Stark wrote: > > Your talking about why we need to still have a push for the features of Unsafe to be exposed in the jdk to allow for innovation? Agreed about that. > > ----- Original Message ----- > From: "Jason Greene" > To: "Scott Stark" > Cc: wildfly-dev at lists.jboss.org > Sent: Tuesday, July 21, 2015 2:01:45 PM > Subject: Re: [wildfly-dev] sun.misc.Unsafe usage, etc. > > Right, it effectively locks us out of creating either derivatives or backports of java.util.concurrent, which is an active project that moves along independently of the JDK, leaving it continually behind. So its still a problem after JDK8. There are ways around it, in that you can port them in many cases to using AtomicXXX or AtomicXXXReferenceFieldUpdater. However, these are currently slower. > >> On Jul 21, 2015, at 3:44 PM, Scott Stark wrote: >> >> One major usage jumping out is that of JSR166 java.util.concurrency class backports. These will be a non-issue once Java 8+ is a requirement. >> >> ----- Original Message ----- >> From: "Scott Stark" >> To: wildfly-dev at lists.jboss.org >> Sent: Tuesday, July 21, 2015 10:58:08 AM >> Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. >> >> In case you didn't see the msg I sent to the core, I started up a discussion thread "What are our middleware sun.misc.Unsafe uses?" (https://developer.jboss.org/message/936359) to identify and track the replacement for all of the Unsafe uses. As the start of the discussion indicates, this came up because there was fear that Java 9 would prevent access to the various internal packages. There may be a Java EC working group on the problem, but it would be best for use to work on getting public replacements in place by working with our OpenJDK team lead by Andrew Haley. >> >> I have some comments I collected from other threads on the topic from Andrew, Jason and David as well as the Java EC summary of the Unsafe situation as background at the start of the thread. >> >> Please add to or correct anything that shows up on the thread as I work through the projects to identify what we are using and why. >> >> The first think I checked out was the use of the Unsafe usage by jboss-modules in the current wildfly trunk build. That turns out to be synchronization primitives that have already been dropped in the 1.5.0 snapshot due to JDK7+ being required. Hopefully most of these are similar workarounds for older Java platforms, but where they are not, I want to make sure we are either tracking or creating an OpenJDK JEP (http://openjdk.java.net/jeps/1) for the public api replacement. >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From anilsaldhana at gmail.com Wed Jul 22 13:26:08 2015 From: anilsaldhana at gmail.com (Anil Saldanha) Date: Wed, 22 Jul 2015 12:26:08 -0500 Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. In-Reply-To: <8BFD699F-0DA0-48A1-80A9-9DE723156ED6@redhat.com> References: <172349015.1843388.1437501488613.JavaMail.zimbra@redhat.com> <483824663.1938782.1437511466370.JavaMail.zimbra@redhat.com> <6A132405-4315-45BF-BF9E-1C17A1FAD2F2@redhat.com> <1934704869.2345817.1437582435109.JavaMail.zimbra@redhat.com> <8BFD699F-0DA0-48A1-80A9-9DE723156ED6@redhat.com> Message-ID: Totally agree with both of you. The reason a discussion on Unsafe is happening after all these years implies that a lot of projects have used it over the years and there is no way to completely shield it. Definitely some mechanism have to be put in place in the JDK to provide hooks to developers who need it. Remember, the setAccessible(true) for private fields? The existence of this mechanism helps when you need it. On Wed, Jul 22, 2015 at 12:15 PM, Jason Greene wrote: > Yes thats exactly what I mean. These low level hooks have been a boon to > innovation, and it would be a shame to stifle that. I am sympathetic to > their desire to not provide compatibility guarantees around these methods, > and to hide them by default. So if they go the route of a flag or a special > module import/permission I think thats reasonable and accomplishes that > goal. I am more worried about them being outright prevented and unreachable. > > > On Jul 22, 2015, at 11:27 AM, Scott Stark wrote: > > > > Your talking about why we need to still have a push for the features of > Unsafe to be exposed in the jdk to allow for innovation? Agreed about that. > > > > ----- Original Message ----- > > From: "Jason Greene" > > To: "Scott Stark" > > Cc: wildfly-dev at lists.jboss.org > > Sent: Tuesday, July 21, 2015 2:01:45 PM > > Subject: Re: [wildfly-dev] sun.misc.Unsafe usage, etc. > > > > Right, it effectively locks us out of creating either derivatives or > backports of java.util.concurrent, which is an active project that moves > along independently of the JDK, leaving it continually behind. So its still > a problem after JDK8. There are ways around it, in that you can port them > in many cases to using AtomicXXX or AtomicXXXReferenceFieldUpdater. > However, these are currently slower. > > > >> On Jul 21, 2015, at 3:44 PM, Scott Stark wrote: > >> > >> One major usage jumping out is that of JSR166 java.util.concurrency > class backports. These will be a non-issue once Java 8+ is a requirement. > >> > >> ----- Original Message ----- > >> From: "Scott Stark" > >> To: wildfly-dev at lists.jboss.org > >> Sent: Tuesday, July 21, 2015 10:58:08 AM > >> Subject: [wildfly-dev] sun.misc.Unsafe usage, etc. > >> > >> In case you didn't see the msg I sent to the core, I started up a > discussion thread "What are our middleware sun.misc.Unsafe uses?" ( > https://developer.jboss.org/message/936359) to identify and track the > replacement for all of the Unsafe uses. As the start of the discussion > indicates, this came up because there was fear that Java 9 would prevent > access to the various internal packages. There may be a Java EC working > group on the problem, but it would be best for use to work on getting > public replacements in place by working with our OpenJDK team lead by > Andrew Haley. > >> > >> I have some comments I collected from other threads on the topic from > Andrew, Jason and David as well as the Java EC summary of the Unsafe > situation as background at the start of the thread. > >> > >> Please add to or correct anything that shows up on the thread as I work > through the projects to identify what we are using and why. > >> > >> The first think I checked out was the use of the Unsafe usage by > jboss-modules in the current wildfly trunk build. That turns out to be > synchronization primitives that have already been dropped in the 1.5.0 > snapshot due to JDK7+ being required. Hopefully most of these are similar > workarounds for older Java platforms, but where they are not, I want to > make sure we are either tracking or creating an OpenJDK JEP ( > http://openjdk.java.net/jeps/1) for the public api replacement. > >> > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > > Jason T. Greene > > WildFly Lead / JBoss EAP Platform Architect > > JBoss, a division of Red Hat > > > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150722/925d5f62/attachment-0001.html From david.lloyd at redhat.com Thu Jul 23 19:11:05 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 23 Jul 2015 18:11:05 -0500 Subject: [wildfly-dev] New WildFly Naming Client library repository Message-ID: <55B17489.9030309@redhat.com> I've published the new naming client library to GitHub under the WildFly org [1]. Features include: * ServiceLoader-based naming providers off of a common initial context * Implementation of the remote-naming protocol using new Remoting connection management * Support for wildfly-client-config configuration file * Proper support for federation * Useful base classes for easily implementing naming subtrees with or without federation support The new EJB client library is already using this support for its "ejb:" scheme, cutting down that project's naming code by an appreciable fraction. As part of the server integration, it is likely that this will be layered in to the server JNDI system. Still TODO: * Per-request security and transaction propagation for the remote naming protocol * Stabilized dependencies so I can tag a release [1] https://github.com/wildfly/wildfly-naming-client -- - DML From jason.greene at redhat.com Fri Jul 24 09:05:06 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Fri, 24 Jul 2015 09:05:06 -0400 (EDT) Subject: [wildfly-dev] 8.2.1.Final & 9.0.1.Final Released Message-ID: <5840B63A-C081-4D3A-A2D2-728E67F3BFD9@redhat.com> Hello Everyone, As some of of have already seen, last night WildFly 9.0.1.Final and 8.2.1.Final were released. These releases include security updates and bug fixes. The issues addressed for 8.2.1 are: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12313721&version=12327667 and include: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12312521&version=12327616 https://github.com/jboss/xerces/pulls?q=is%3Apr+is%3Aclosed The issues addressed for 9.0.1 are: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12313721&version=12327668 and include https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12312521&version=12327529 Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150724/5381fbee/attachment.html From tomaz.cerar at gmail.com Fri Jul 24 13:13:25 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 24 Jul 2015 19:13:25 +0200 Subject: [wildfly-dev] Removing wildfly embedded In-Reply-To: References: Message-ID: No replies would probably mean that everyone agrees with this. So here is the PR to remove it https://github.com/wildfly/wildfly/pull/7743 -- tomaz On Wed, Jul 22, 2015 at 2:35 PM, Toma? Cerar wrote: > Hi folks, > > I was wondering if we could remove wildfly-embedded (GAV: > org.wildfly:wildfly-embedded) > https://github.com/wildfly/wildfly/tree/master/embedded module > > given that we now have better embedded in WildFly-core (GAV: > org.wildfly.core:wildfly-embedded) > https://github.com/wildfly/wildfly-core/tree/master/embedded > > Only user we had (that I know of) was WildFly arquillian adapter but that > was moved to wildfly-core's embedded already. > > So any objections to removing embedded from WldFly full codebase? > > any potential users should migrate can easily migrate to new API if they > desire. > > -- > tomaz > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150724/0f41ce62/attachment.html From brian.stansberry at redhat.com Fri Jul 24 13:59:05 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Fri, 24 Jul 2015 12:59:05 -0500 Subject: [wildfly-dev] Capabilities enabled by attributes Message-ID: <55B27CE9.2000708@redhat.com> I would like to propose a requirement that if a particular type of resource CAN provide a capability, then it MUST provide that capability if it is created. There will be no such thing as a resource providing or not providing a capability based on the value of one of its attributes. My question to subsystem developers is whether they have a situation in their configuration model where this will be a problem? For any case where there is such an attribute, the requirement would mean that a child resource would need to be created instead, and that child resource would provide the capability. There are tricks we can use to preserve the existing attribute to provide management API compatibility. The only case I'm aware of where this is a factor is the 'jts' attribute in the subsystem=transactions resource. The reason for this requirement is we want tooling to be able to inspect the types of resources that are available for use, see what capabilities they provide and what requirements they have, and work out what resources need to be present in a configuration in order to have a consistent set of capabilities. That task is significantly more complex if the presence of a capability is determined by some arbitrary attribute value. David Lloyd described allowing attributes to control this as being "like creating an RDBMS where you have foreign keys that only exist if some function evaluates in a certain way." -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From fjuma at redhat.com Mon Jul 27 11:57:46 2015 From: fjuma at redhat.com (Farah Juma) Date: Mon, 27 Jul 2015 11:57:46 -0400 (EDT) Subject: [wildfly-dev] WildFly 8.2.1.Final and 9.0.1.Final are now on OpenShift In-Reply-To: <1858638740.355883.1438011286178.JavaMail.zimbra@redhat.com> Message-ID: <1762853941.424856.1438012666840.JavaMail.zimbra@redhat.com> Details for getting started can be found here: 8.2.1.Final: https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-8 9.0.1.Final: https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-9 From sanne at hibernate.org Tue Jul 28 08:25:56 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Tue, 28 Jul 2015 15:25:56 +0300 Subject: [wildfly-dev] Handling Unsafe as an optional dependency Message-ID: Hi all, while checking dependencies of some Hibernate projects for usage of sun.misc.Unsafe I've found that Apache Avro uses it, but it's "optional". When allowing it to use Unsafe it will be more efficient. Avro automatically attempts to use it, and in case of failure hide the exception and store this information in a static field, to consistently resort to Reflection API as a fallback. For this to work at all I guess I should be adding the module dependency to "sun.jdk". Shall I add this dependency to benefit from it as long as it's an option, or just have it forget about Unsafe already? We could also set the property avro.disable.unsafe=true to avoid the usage attempt. Thanks, Sanne From david.lloyd at redhat.com Tue Jul 28 08:48:38 2015 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 28 Jul 2015 07:48:38 -0500 Subject: [wildfly-dev] Handling Unsafe as an optional dependency In-Reply-To: References: Message-ID: <55B77A26.3090600@redhat.com> On 07/28/2015 07:25 AM, Sanne Grinovero wrote: > Hi all, > while checking dependencies of some Hibernate projects for usage of > sun.misc.Unsafe I've found that Apache Avro uses it, but it's > "optional". > > When allowing it to use Unsafe it will be more efficient. Avro > automatically attempts to use it, and in case of failure hide the > exception and store this information in a static field, to > consistently resort to Reflection API as a fallback. > > For this to work at all I guess I should be adding the module > dependency to "sun.jdk". > > Shall I add this dependency to benefit from it as long as it's an > option, or just have it forget about Unsafe already? Go ahead and add the dependency IMO. -- - DML From spaulger at codezen.co.uk Tue Jul 28 16:04:33 2015 From: spaulger at codezen.co.uk (Simon Paulger) Date: Tue, 28 Jul 2015 21:04:33 +0100 Subject: [wildfly-dev] Wildfly Redis infinispan cache store Message-ID: Hi, My company uses JBoss AS 7 (before Wildfly I know). We also use Redis cache store for PHP stacks and I'd like to be able to do the same for Wildfly (I'm considering upgrade paths). I see there is an old JIRA enhancement issue raised here: https://issues.jboss.org/browse/ISPN-3465 I was wondering what the appetite for creating a Redis cache store is. If this were something I were to develop in both inifinispan and wildfly, would it be well received by the JBoss community? Regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150728/a35c22e5/attachment.html From jason.greene at redhat.com Tue Jul 28 16:22:06 2015 From: jason.greene at redhat.com (Jason Greene) Date: Tue, 28 Jul 2015 15:22:06 -0500 Subject: [wildfly-dev] Wildfly Redis infinispan cache store In-Reply-To: References: Message-ID: > On Jul 28, 2015, at 3:04 PM, Simon Paulger wrote: > > Hi, > > My company uses JBoss AS 7 (before Wildfly I know). We also use Redis cache store for PHP stacks and I'd like to be able to do the same for Wildfly (I'm considering upgrade paths). > > I see there is an old JIRA enhancement issue raised here: https://issues.jboss.org/browse/ISPN-3465 > > I was wondering what the appetite for creating a Redis cache store is. If this were something I were to develop in both inifinispan and wildfly, would it be well received by the JBoss community? Hi Simon, Thanks for the interest, and it sounds great to me! I would recommend starting by posting to infinispan-dev your interest in the feature (if you haven?t already), and they can help you get started. I would imagine the infinispan memcached code is a good starting point, and may in fact be adaptable to the Redis protocol, perhaps by forking it. One thats done there is some integration bits on the WildFly side, but I wouldn?t worry about that until its shipped in an infinispan release. Thanks, -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150728/403b6290/attachment-0001.html