From stuart.w.douglas at gmail.com Tue Jan 6 20:19:54 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 07 Jan 2015 01:19:54 +0000 Subject: [wildfly-dev] ALPN support Message-ID: Hi all, Both SPDY and the upcoming HTTP2 protocol require the use of an SSL extension called ALPN (Application Layer Protocol Negotiation). Unfortunately this is not supported in current JDK's (it should appear in JDK9), so the only way to support these protocols in Java at the moment is to modify the boot class path and override the JDK SSL classes to add support for this. In practice this means add jetty-alpn-boot.jar to the boot class path, however the exact version of the jar that is required depends on the JVM version, which means we can't just ship a jar and add the boot class path stuff to our startup scripts. I have come up with a proof on concept[1] for how to deal with this, that will download the appropriate ALPN jar for the current server if -alpn is passed to the startup script, however we still need some way to handle this in domain mode, where we need to make sure the servers are all started with the appropriate parameter (worst case we could just require users to install the appropriate JAR themselves, and then set the appropriate JAVA_OPTS). Hopefully the need for this will go away with Java 9, so I am not sure how much effort we should spend dealing with this. Does anyone have any thoughts on this? Stuart [1] https://github.com/stuartwdouglas/wildfly-core/compare/wildfly:master...stuartwdouglas:alpn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150107/9ecec9e6/attachment-0001.html From jason.greene at redhat.com Tue Jan 6 22:39:26 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Tue, 6 Jan 2015 22:39:26 -0500 (EST) Subject: [wildfly-dev] ALPN support In-Reply-To: References: Message-ID: <7506DFED-EFE6-4981-810D-52525B3F6973@redhat.com> We should probably download these jars using a directory or file name convention that is associated with the particular jvm version. That way it becomes easy to support multiple jvm version environments which is very common (both in domain and standalone). In domain mode we could have the host controller bootstrap follow the same approach as standalone. For domain server configured jvms we could reuse the logic as part of the JVM argument building process. > On Jan 6, 2015, at 7:20 PM, Stuart Douglas wrote: > > Hi all, > Both SPDY and the upcoming HTTP2 protocol require the use of an SSL extension called ALPN (Application Layer Protocol Negotiation). Unfortunately this is not supported in current JDK's (it should appear in JDK9), so the only way to support these protocols in Java at the moment is to modify the boot class path and override the JDK SSL classes to add support for this. > > In practice this means add jetty-alpn-boot.jar to the boot class path, however the exact version of the jar that is required depends on the JVM version, which means we can't just ship a jar and add the boot class path stuff to our startup scripts. > > I have come up with a proof on concept[1] for how to deal with this, that will download the appropriate ALPN jar for the current server if -alpn is passed to the startup script, however we still need some way to handle this in domain mode, where we need to make sure the servers are all started with the appropriate parameter (worst case we could just require users to install the appropriate JAR themselves, and then set the appropriate JAVA_OPTS). > > Hopefully the need for this will go away with Java 9, so I am not sure how much effort we should spend dealing with this. > > Does anyone have any thoughts on this? > > Stuart > > [1] https://github.com/stuartwdouglas/wildfly-core/compare/wildfly:master...stuartwdouglas:alpn > > _______________________________________________ > 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/20150106/257cf810/attachment.html From stuart.w.douglas at gmail.com Tue Jan 6 23:50:18 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Wed, 07 Jan 2015 04:50:18 +0000 Subject: [wildfly-dev] ALPN support References: <7506DFED-EFE6-4981-810D-52525B3F6973@redhat.com> Message-ID: My POC downloads a mapping file, that maps the JVM version to a specific artefact. Stuart On Wed Jan 07 2015 at 2:39:27 PM Jason T. Greene wrote: > We should probably download these jars using a directory or file name > convention that is associated with the particular jvm version. That way it > becomes easy to support multiple jvm version environments which is very > common (both in domain and standalone). > > In domain mode we could have the host controller bootstrap follow the same > approach as standalone. For domain server configured jvms we could reuse > the logic as part of the JVM argument building process. > > On Jan 6, 2015, at 7:20 PM, Stuart Douglas > wrote: > > Hi all, > Both SPDY and the upcoming HTTP2 protocol require the use of an SSL > extension called ALPN (Application Layer Protocol Negotiation). > Unfortunately this is not supported in current JDK's (it should appear in > JDK9), so the only way to support these protocols in Java at the moment is > to modify the boot class path and override the JDK SSL classes to add > support for this. > > In practice this means add jetty-alpn-boot.jar to the boot class path, > however the exact version of the jar that is required depends on the JVM > version, which means we can't just ship a jar and add the boot class path > stuff to our startup scripts. > > I have come up with a proof on concept[1] for how to deal with this, that > will download the appropriate ALPN jar for the current server if -alpn is > passed to the startup script, however we still need some way to handle this > in domain mode, where we need to make sure the servers are all started with > the appropriate parameter (worst case we could just require users to > install the appropriate JAR themselves, and then set the appropriate > JAVA_OPTS). > > Hopefully the need for this will go away with Java 9, so I am not sure how > much effort we should spend dealing with this. > > Does anyone have any thoughts on this? > > Stuart > > [1] > https://github.com/stuartwdouglas/wildfly-core/compare/wildfly:master...stuartwdouglas:alpn > > > _______________________________________________ > 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/20150107/850cb71b/attachment.html From hbraun at redhat.com Wed Jan 7 09:13:45 2015 From: hbraun at redhat.com (Heiko Braun) Date: Wed, 7 Jan 2015 15:13:45 +0100 Subject: [wildfly-dev] WildFly domain on OpenShift Origin In-Reply-To: <25721500-EF9C-43C0-A5EA-87988A8FB2F2@redhat.com> References: <9972200F-E4C9-4E30-9DD0-C4EB7017AB47@redhat.com> <44C922B6-FD83-44DF-9DC5-87D7AED804DA@redhat.com> <5491964A.3040306@redhat.com> <89148630-C30C-4783-8FFD-38F452DDE94A@redhat.com> <25721500-EF9C-43C0-A5EA-87988A8FB2F2@redhat.com> Message-ID: <27BF6301-ABE5-4835-9CB2-625DA556F84F@redhat.com> Did you already provide a link to that document? /Heiko > Am 18.12.2014 um 09:26 schrieb Thomas Diesler : > > Lets start with requirements and a design that everybody who has a stake in this can be agreed on - I?ll get a doc started. > >> On 18 Dec 2014, at 09:18, James Strachan wrote: >> >> If the EAP console is available as a Kubernetes Service we can easily add it to the hawtio nav bar like we do with Kibana, Grafana et al. >> >>> On 17 Dec 2014, at 16:17, Thomas Diesler wrote: >>> >>> Thanks James, >>> >>> I?ll look at the fabric8 hawtio console next I see if I can get it to work alongside with the wildfly console. Then I think I should meet with Heiko/Harald (for a long walk) and we talk about this some more. >>> >>> ?thomas >>> >>> >>> >>>> On 17 Dec 2014, at 15:59, James Strachan wrote: >>>> >>>> A persistent volume could be used for the pod running the DC; if the pod is restarted or if it fails over to another host the persistent volume will be preserved (using one of the shared volume mechanisms in kubernetes/openshift like Ceph/Gluster/Cinder/S3/EBS etc) >>>> >>>>> On 17 Dec 2014, at 14:42, Brian Stansberry wrote: >>>>> >>>>>> On 12/17/14, 3:28 AM, Thomas Diesler wrote: >>>>>> Folks, >>>>>> >>>>>> following up on this topic, I worked a little more on WildFly-Camel in >>>>>> Kubernetes/OpenShift. >>>>>> >>>>>> These doc pages are targeted for the upcoming 2.1.0 release (01-Feb-2015) >>>>>> >>>>>> * WildFly-Camel on Docker >>>>>> >>>>>> * WildFly-Camel on OpenShift >>>>>> >>>>> >>>>> Great. :) >>>>> >>>>>> >>>>>> The setup looks like this >>>>>> >>>>>> >>>>>> We can now manage these individual wildfly nodes. The domain controller >>>>>> (DC) is replicated once, the host definition is replicated three times. >>>>>> Theoretically, this means that there is no single point of failure with >>>>>> the domain controller any more - kube would respawn the DC on failure >>>>> >>>>> I'm heading on PTO tomorrow so likely won't be able to follow up on this question for a while, but one concern I had with the Kubernetes respawn approach was retaining any changes that had been made to the domain configuration. Unless the domain.xml comes from / is written to some shared storage available to the respawned DC, any changes made will be lost. >>>>> >>>>> Of course, if the DC is only being used for reads, this isn't an issue. >>>>> >>>>>> Here some ideas for improvement ? >>>>>> >>>>>> In a kube env we should be able to swap out containers based on some >>>>>> criteria. It should be possible to define these criteria, emit events >>>>>> based on them create/remove/replace containers automatically. >>>>>> Additionally a human should be able to make qualified decisions through >>>>>> a console and create/remove/replace containers easily. >>>>>> Much of the needed information is in jmx. Heiko told me that there is a >>>>>> project that can push events to influx db - something to look at. >>>>>> >>>>>> If information display contained in jmx in a console has value (e.g in >>>>>> hawtio) that information must be aggregated and visible for each node. >>>>>> Currently, we have a round robin service on 8080 which would show a >>>>>> different hawtio instance on every request - this is nonsense. >>>>>> >>>>>> I can see a number of high level items: >>>>>> >>>>>> #1 a thing that aggregates jmx content - possibly multiple MBeanServers >>>>>> in the DC VM that delegate to respective MBeanServers on other hosts, so >>>>>> that a management client can pickup the info from one service >>>>>> #2 look at the existing inluxdb thing and research into how to automate >>>>>> the replacement of containers >>>>>> #3 from the usability perspective, there may need to be an openshift >>>>>> profile in the console(s) because some operations may not make sense in >>>>>> that env >>>>>> >>>>>> cheers >>>>>> ?thomas >>>>>> >>>>>> PS: looking forward to an exiting ride in 2015 >>>>>> >>>>>> >>>>>>> On 5 Dec 2014, at 14:36, Thomas Diesler >>>>>> > wrote: >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> I?ve recently been looking at WildFly container deployments on >>>>>>> OpenShift V3. The following setup is documented here >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The example architecture consists of a set of three high available >>>>>>> (HA) servers running REST endpoints. >>>>>>> For server replication and failover we use Kubernetes. Each server >>>>>>> runs in a dedicated Pod that we access via Services. >>>>>>> >>>>>>> This approach comes with a number of benefits, which are sufficiently >>>>>>> explained in various OpenShift >>>>>>> , >>>>>>> Kubernetes >>>>>>> and >>>>>>> Docker materials, but also with a number of >>>>>>> challenges. Lets look at those in more detail ? >>>>>>> >>>>>>> In the example above Kubernetes replicates a number of standalone >>>>>>> containers and isolates them in a Pod each with limited access from >>>>>>> the outside world. >>>>>>> >>>>>>> * The management interfaces are not accessible >>>>>>> * The management consoles are not visible >>>>>>> >>>>>>> With WildFly-Camel we have a Hawt.io >>>>>>> console >>>>>>> that allows us to manage Camel Routes configured or deployed to the >>>>>>> WildFly runtime. >>>>>>> The WildFly console manages aspects of the appserver. >>>>>>> >>>>>>> In a more general sense, I was wondering how the WildFly domain model >>>>>>> maps to the Kubernetes runtime environment and how these server >>>>>>> instances are managed and information about them relayed back to the >>>>>>> sysadmin >>>>>>> >>>>>>> a) Should these individual wildfly instances somehow be connected to >>>>>>> each other (i.e. notion of domain)? >>>>>>> b) How would an HA singleton service work? >>>>>>> c) What level of management should be exposed to the outside? >>>>>>> d) Should it be possible to modify runtime behaviour of these servers >>>>>>> (i.e. write access to config)? >>>>>>> e) Should deployment be supported at all? >>>>>>> f) How can a server be detected that has gone bad? >>>>>>> g) Should logs be aggregated? >>>>>>> h) Should there be a common management view (i.e. console) for these >>>>>>> servers? >>>>>>> i) etc ? >>>>>>> >>>>>>> Are these concerns already being addressed for WildFly? >>>>>>> >>>>>>> Is there perhaps even an already existing design that I could look at? >>>>>>> >>>>>>> Can such an effort be connected to the work that is going on in Fabric8? >>>>>>> >>>>>>> cheers >>>>>>> ?thomas >>>>>>> >>>>>>> PS: it would be area that we @ wildfly-camel were interested to work on >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> >>>> James >>>> ------- >>>> Red Hat >>>> >>>> Twitter: @jstrachan >>>> Email: jstracha at redhat.com >>>> Blog: http://macstrac.blogspot.com/ >>>> >>>> hawtio: http://hawt.io/ >>>> fabric8: http://fabric8.io/ >>>> >>>> Open Source Integration >> >> >> James >> ------- >> Red Hat >> >> Twitter: @jstrachan >> Email: jstracha at redhat.com >> Blog: http://macstrac.blogspot.com/ >> >> hawtio: http://hawt.io/ >> fabric8: http://fabric8.io/ >> >> Open Source Integration > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150107/7a4b640b/attachment-0001.html From tdiesler at redhat.com Wed Jan 7 09:28:32 2015 From: tdiesler at redhat.com (Thomas Diesler) Date: Wed, 7 Jan 2015 15:28:32 +0100 Subject: [wildfly-dev] WildFly domain on OpenShift Origin In-Reply-To: <27BF6301-ABE5-4835-9CB2-625DA556F84F@redhat.com> References: <9972200F-E4C9-4E30-9DD0-C4EB7017AB47@redhat.com> <44C922B6-FD83-44DF-9DC5-87D7AED804DA@redhat.com> <5491964A.3040306@redhat.com> <89148630-C30C-4783-8FFD-38F452DDE94A@redhat.com> <25721500-EF9C-43C0-A5EA-87988A8FB2F2@redhat.com> <27BF6301-ABE5-4835-9CB2-625DA556F84F@redhat.com> Message-ID: what I have is here https://github.com/wildfly-extras/wildfly-camel-book/blob/2.1/cloud/README.md it runs a wildfly domain on OS and accesses the management interface from the EC2 instance. Due to a public port exposure bug in kubernetes we can?t see the web console yet, but that should be fixed sonn (if it isn?t already). cheers ?thomas > On 7 Jan 2015, at 15:13, Heiko Braun wrote: > > Did you already provide a link to that document? > > /Heiko > > > > > Am 18.12.2014 um 09:26 schrieb Thomas Diesler >: > >> Lets start with requirements and a design that everybody who has a stake in this can be agreed on - I?ll get a doc started. >> >>> On 18 Dec 2014, at 09:18, James Strachan > wrote: >>> >>> If the EAP console is available as a Kubernetes Service we can easily add it to the hawtio nav bar like we do with Kibana, Grafana et al. >>> >>>> On 17 Dec 2014, at 16:17, Thomas Diesler > wrote: >>>> >>>> Thanks James, >>>> >>>> I?ll look at the fabric8 hawtio console next I see if I can get it to work alongside with the wildfly console. Then I think I should meet with Heiko/Harald (for a long walk) and we talk about this some more. >>>> >>>> ?thomas >>>> >>>> >>>> >>>>> On 17 Dec 2014, at 15:59, James Strachan > wrote: >>>>> >>>>> A persistent volume could be used for the pod running the DC; if the pod is restarted or if it fails over to another host the persistent volume will be preserved (using one of the shared volume mechanisms in kubernetes/openshift like Ceph/Gluster/Cinder/S3/EBS etc) >>>>> >>>>>> On 17 Dec 2014, at 14:42, Brian Stansberry > wrote: >>>>>> >>>>>> On 12/17/14, 3:28 AM, Thomas Diesler wrote: >>>>>>> Folks, >>>>>>> >>>>>>> following up on this topic, I worked a little more on WildFly-Camel in >>>>>>> Kubernetes/OpenShift. >>>>>>> >>>>>>> These doc pages are targeted for the upcoming 2.1.0 release (01-Feb-2015) >>>>>>> >>>>>>> * WildFly-Camel on Docker >>>>>>> > >>>>>>> * WildFly-Camel on OpenShift >>>>>>> > >>>>>>> >>>>>> >>>>>> Great. :) >>>>>> >>>>>>> >>>>>>> The setup looks like this >>>>>>> >>>>>>> >>>>>>> We can now manage these individual wildfly nodes. The domain controller >>>>>>> (DC) is replicated once, the host definition is replicated three times. >>>>>>> Theoretically, this means that there is no single point of failure with >>>>>>> the domain controller any more - kube would respawn the DC on failure >>>>>>> >>>>>> >>>>>> I'm heading on PTO tomorrow so likely won't be able to follow up on this question for a while, but one concern I had with the Kubernetes respawn approach was retaining any changes that had been made to the domain configuration. Unless the domain.xml comes from / is written to some shared storage available to the respawned DC, any changes made will be lost. >>>>>> >>>>>> Of course, if the DC is only being used for reads, this isn't an issue. >>>>>> >>>>>>> Here some ideas for improvement ? >>>>>>> >>>>>>> In a kube env we should be able to swap out containers based on some >>>>>>> criteria. It should be possible to define these criteria, emit events >>>>>>> based on them create/remove/replace containers automatically. >>>>>>> Additionally a human should be able to make qualified decisions through >>>>>>> a console and create/remove/replace containers easily. >>>>>>> Much of the needed information is in jmx. Heiko told me that there is a >>>>>>> project that can push events to influx db - something to look at. >>>>>>> >>>>>>> If information display contained in jmx in a console has value (e.g in >>>>>>> hawtio) that information must be aggregated and visible for each node. >>>>>>> Currently, we have a round robin service on 8080 which would show a >>>>>>> different hawtio instance on every request - this is nonsense. >>>>>>> >>>>>>> I can see a number of high level items: >>>>>>> >>>>>>> #1 a thing that aggregates jmx content - possibly multiple MBeanServers >>>>>>> in the DC VM that delegate to respective MBeanServers on other hosts, so >>>>>>> that a management client can pickup the info from one service >>>>>>> #2 look at the existing inluxdb thing and research into how to automate >>>>>>> the replacement of containers >>>>>>> #3 from the usability perspective, there may need to be an openshift >>>>>>> profile in the console(s) because some operations may not make sense in >>>>>>> that env >>>>>>> >>>>>>> cheers >>>>>>> ?thomas >>>>>>> >>>>>>> PS: looking forward to an exiting ride in 2015 >>>>>>> >>>>>>> >>>>>>>> On 5 Dec 2014, at 14:36, Thomas Diesler >>>>>>>> >> wrote: >>>>>>>> >>>>>>>> Folks, >>>>>>>> >>>>>>>> I?ve recently been looking at WildFly container deployments on >>>>>>>> OpenShift V3. The following setup is documented here >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The example architecture consists of a set of three high available >>>>>>>> (HA) servers running REST endpoints. >>>>>>>> For server replication and failover we use Kubernetes. Each server >>>>>>>> runs in a dedicated Pod that we access via Services. >>>>>>>> >>>>>>>> This approach comes with a number of benefits, which are sufficiently >>>>>>>> explained in various OpenShift >>>>>>>> >, >>>>>>>> Kubernetes >>>>>>>> > and >>>>>>>> Docker > materials, but also with a number of >>>>>>>> challenges. Lets look at those in more detail ? >>>>>>>> >>>>>>>> In the example above Kubernetes replicates a number of standalone >>>>>>>> containers and isolates them in a Pod each with limited access from >>>>>>>> the outside world. >>>>>>>> >>>>>>>> * The management interfaces are not accessible >>>>>>>> * The management consoles are not visible >>>>>>>> >>>>>>>> With WildFly-Camel we have a Hawt.io >>>>>>>> > console >>>>>>>> that allows us to manage Camel Routes configured or deployed to the >>>>>>>> WildFly runtime. >>>>>>>> The WildFly console manages aspects of the appserver. >>>>>>>> >>>>>>>> In a more general sense, I was wondering how the WildFly domain model >>>>>>>> maps to the Kubernetes runtime environment and how these server >>>>>>>> instances are managed and information about them relayed back to the >>>>>>>> sysadmin >>>>>>>> >>>>>>>> a) Should these individual wildfly instances somehow be connected to >>>>>>>> each other (i.e. notion of domain)? >>>>>>>> b) How would an HA singleton service work? >>>>>>>> c) What level of management should be exposed to the outside? >>>>>>>> d) Should it be possible to modify runtime behaviour of these servers >>>>>>>> (i.e. write access to config)? >>>>>>>> e) Should deployment be supported at all? >>>>>>>> f) How can a server be detected that has gone bad? >>>>>>>> g) Should logs be aggregated? >>>>>>>> h) Should there be a common management view (i.e. console) for these >>>>>>>> servers? >>>>>>>> i) etc ? >>>>>>>> >>>>>>>> Are these concerns already being addressed for WildFly? >>>>>>>> >>>>>>>> Is there perhaps even an already existing design that I could look at? >>>>>>>> >>>>>>>> Can such an effort be connected to the work that is going on in Fabric8? >>>>>>>> >>>>>>>> cheers >>>>>>>> ?thomas >>>>>>>> >>>>>>>> PS: it would be area that we @ wildfly-camel were interested to work on >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> >>>>> >>>>> James >>>>> ------- >>>>> Red Hat >>>>> >>>>> Twitter: @jstrachan >>>>> Email: jstracha at redhat.com >>>>> Blog: http://macstrac.blogspot.com/ >>>>> >>>>> hawtio: http://hawt.io/ >>>>> fabric8: http://fabric8.io/ >>>>> >>>>> Open Source Integration >>>>> >>>> >>> >>> >>> James >>> ------- >>> Red Hat >>> >>> Twitter: @jstrachan >>> Email: jstracha at redhat.com >>> Blog: http://macstrac.blogspot.com/ >>> >>> hawtio: http:/ /hawt.io/ >>> fabric8: http:/ /fabric8.io/ >>> >>> Open Source Integration >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150107/cd769927/attachment-0001.html From jmartisk at redhat.com Thu Jan 8 04:53:14 2015 From: jmartisk at redhat.com (Jan =?utf-8?Q?Marti=C5=A1ka?=) Date: Thu, 8 Jan 2015 04:53:14 -0500 (EST) Subject: [wildfly-dev] Property substitution in EE annotations In-Reply-To: <1690091153.4351349.1420710521098.JavaMail.zimbra@redhat.com> Message-ID: <1334664799.4352589.1420710794523.JavaMail.zimbra@redhat.com> Hi, let me ask a question. I am playing with property substitution in Java EE applications and I can't get it to work with annotations in anything else than EJB-related stuff (javax.ejb.* annotations). I tried so far: - @javax.persistence.Table's name to parametrize the table name for an entity - @javax.validation.constraints.Pattern's regexp parameter to parametrize a regular expression which validates a string Neither of these seems to work for me --- Hibernate and Hibernate Validator see and try to use the raw string that I specified in the annotation (and of course fail because the syntax is wrong). I have the /subsystem=ee:annotation-property-replacement=true, of course. As I said, for EJB-related things it works well (even when I add them to the same application). I'm trying with the current WildFly master as well as EAP 6.3. Per https://issues.jboss.org/browse/WFLY-2855 I understand that property replacement is meant to work with all Java EE annotations. Is this expected, is it a bug, or might I be missing something? Thanks! Jan From chaowan at redhat.com Thu Jan 8 05:32:20 2015 From: chaowan at redhat.com (Chao Wang) Date: Thu, 08 Jan 2015 18:32:20 +0800 Subject: [wildfly-dev] Property substitution in EE annotations In-Reply-To: <1334664799.4352589.1420710794523.JavaMail.zimbra@redhat.com> References: <1334664799.4352589.1420710794523.JavaMail.zimbra@redhat.com> Message-ID: <54AE5CB4.609@redhat.com> On 01/08/2015 05:53 PM, Jan Marti?ka wrote: > Hi, > let me ask a question. I am playing with property substitution in Java EE applications and I can't get it to work with annotations in anything else than EJB-related stuff (javax.ejb.* annotations). I tried so far: > - @javax.persistence.Table's name to parametrize the table name for an entity > - @javax.validation.constraints.Pattern's regexp parameter to parametrize a regular expression which validates a string > > Neither of these seems to work for me --- Hibernate and Hibernate Validator see and try to use the raw string that I specified in the annotation (and of course fail because the syntax is wrong). > I have the /subsystem=ee:annotation-property-replacement=true, of course. As I said, for EJB-related things it works well (even when I add them to the same application). > > I'm trying with the current WildFly master as well as EAP 6.3. > Per https://issues.jboss.org/browse/WFLY-2855 I understand that property replacement is meant to work with all Java EE annotations. > > Is this expected, is it a bug, or might I be missing something? > > Thanks! > Jan > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev It's not done for all Java EE annotations. At present, It only works for EJB related annotations from package below : EJB Types: javax.ejb JBoss Ejb3 extension: jboss-ejb3-ext-api Resource injection: javax.annotation Security: javax.annotation.security cheers, Chao From eduardo.santanadasilva at gmail.com Thu Jan 8 11:16:27 2015 From: eduardo.santanadasilva at gmail.com (Eduardo Sant'Ana da Silva) Date: Thu, 8 Jan 2015 14:16:27 -0200 Subject: [wildfly-dev] WSTestCase is failing - http://webservices.smoke.test.as.jboss.org/ Message-ID: <23E1EC02-E4F8-49E0-9124-86B0E7F3CE07@gmail.com> Hello, I'm not able to do a build with the latest version (9ae8a8d600dedd6aa6e80d469921aa2d8ee43eb1) , the test case WSTestCase is failing. It is trying to connect with http://webservices.smoke.test.as.jboss.org/, that is unreachable. 14:04:24,873 WARN [org.apache.cxf.phase.PhaseInterceptorChain] (main) Interceptor for {http://webservices.smoke.test.as.jboss.org/}EndpointService#{http://webservices.smoke.test.as.jboss.org/}echoString has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: Could not send Message. Am I doing something wrong? Is there anything to configure to override this address? Regards, Eduardo Sant'Ana da Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150108/ab8b54b5/attachment.html From tomaz.cerar at gmail.com Thu Jan 8 18:46:41 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 9 Jan 2015 00:46:41 +0100 Subject: [wildfly-dev] WSTestCase is failing - http://webservices.smoke.test.as.jboss.org/ In-Reply-To: <23E1EC02-E4F8-49E0-9124-86B0E7F3CE07@gmail.com> References: <23E1EC02-E4F8-49E0-9124-86B0E7F3CE07@gmail.com> Message-ID: This is a bug! No test should be testing against external resource like this. Can you create jira for this? On Thu, Jan 8, 2015 at 5:16 PM, Eduardo Sant'Ana da Silva < eduardo.santanadasilva at gmail.com> wrote: > Hello, > > I'm not able to do a build with the latest version > (9ae8a8d600dedd6aa6e80d469921aa2d8ee43eb1) , the test case WSTestCase is > failing. > It is trying to connect with http://webservices.smoke.test.as.jboss.org/, > that is unreachable. > > > 14:04:24,873 WARN [org.apache.cxf.phase.PhaseInterceptorChain] (main) > Interceptor for {http://webservices.smoke.test.as.jboss.org/ > }EndpointService#{http://webservices.smoke.test.as.jboss.org/}echoString > has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: > Could not send Message. > > Am I doing something wrong? Is there anything to configure to override > this address? > > Regards, > 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/20150109/a5f2e2d5/attachment.html From eduardo.santanadasilva at gmail.com Thu Jan 8 18:55:01 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Thu, 8 Jan 2015 21:55:01 -0200 Subject: [wildfly-dev] WSTestCase is failing - http://webservices.smoke.test.as.jboss.org/ In-Reply-To: References: <23E1EC02-E4F8-49E0-9124-86B0E7F3CE07@gmail.com> Message-ID: Yes, but first I'll double check this, something is weird, this URL seems to be assembled from the namespace used on the test case. I think that I'm missing something. Thanks Eduardo S. 2015-01-08 21:46 GMT-02:00 Toma? Cerar : > This is a bug! > > No test should be testing against external resource like this. > > Can you create jira for this? > > On Thu, Jan 8, 2015 at 5:16 PM, Eduardo Sant'Ana da Silva < > eduardo.santanadasilva at gmail.com> wrote: > >> Hello, >> >> I'm not able to do a build with the latest version >> (9ae8a8d600dedd6aa6e80d469921aa2d8ee43eb1) , the test case WSTestCase is >> failing. >> It is trying to connect with http://webservices.smoke.test.as.jboss.org/, >> that is unreachable. >> >> >> 14:04:24,873 WARN [org.apache.cxf.phase.PhaseInterceptorChain] (main) >> Interceptor for {http://webservices.smoke.test.as.jboss.org/ >> }EndpointService#{http://webservices.smoke.test.as.jboss.org/}echoString >> has thrown exception, unwinding now: org.apache.cxf.interceptor.Fault: >> Could not send Message. >> >> Am I doing something wrong? Is there anything to configure to override >> this address? >> >> Regards, >> 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/20150108/15754062/attachment.html From stuart.w.douglas at gmail.com Sun Jan 11 21:00:20 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Mon, 12 Jan 2015 02:00:20 +0000 Subject: [wildfly-dev] ALPN support References: <7506DFED-EFE6-4981-810D-52525B3F6973@redhat.com> Message-ID: So I guess the real issue for domain mode is how we actually tell the configured servers to use the ALPN jar, especially given that this situation will likely be temporary, and not be required for Java 9+. One option could be that if the -alpn option is passed to the host controller on boot then all servers that it spawns will also have alpn on the boot class path, but that just seems really hacky. Another option would be to just require the user to setup the correct -Xbootclasspath option manually in the JVM arguments. This is not very user friendly though. Stuart On Wed Jan 07 2015 at 2:39:27 PM Jason T. Greene wrote: > We should probably download these jars using a directory or file name > convention that is associated with the particular jvm version. That way it > becomes easy to support multiple jvm version environments which is very > common (both in domain and standalone). > > In domain mode we could have the host controller bootstrap follow the same > approach as standalone. For domain server configured jvms we could reuse > the logic as part of the JVM argument building process. > > On Jan 6, 2015, at 7:20 PM, Stuart Douglas > wrote: > > Hi all, > Both SPDY and the upcoming HTTP2 protocol require the use of an SSL > extension called ALPN (Application Layer Protocol Negotiation). > Unfortunately this is not supported in current JDK's (it should appear in > JDK9), so the only way to support these protocols in Java at the moment is > to modify the boot class path and override the JDK SSL classes to add > support for this. > > In practice this means add jetty-alpn-boot.jar to the boot class path, > however the exact version of the jar that is required depends on the JVM > version, which means we can't just ship a jar and add the boot class path > stuff to our startup scripts. > > I have come up with a proof on concept[1] for how to deal with this, that > will download the appropriate ALPN jar for the current server if -alpn is > passed to the startup script, however we still need some way to handle this > in domain mode, where we need to make sure the servers are all started with > the appropriate parameter (worst case we could just require users to > install the appropriate JAR themselves, and then set the appropriate > JAVA_OPTS). > > Hopefully the need for this will go away with Java 9, so I am not sure how > much effort we should spend dealing with this. > > Does anyone have any thoughts on this? > > Stuart > > [1] > https://github.com/stuartwdouglas/wildfly-core/compare/wildfly:master...stuartwdouglas:alpn > > > _______________________________________________ > 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/20150112/c22169a5/attachment-0001.html From tomaz.cerar at gmail.com Mon Jan 12 10:27:19 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Mon, 12 Jan 2015 16:27:19 +0100 Subject: [wildfly-dev] Core releases missing distribution binaries Message-ID: Hey guys, Can we make sure that also zip files with release of wildfly core is published in maven repo. as for last few releases we are missing it. This makes it hard to consume core itself for anything but usage in WildFly full. so guys that are doing releases, please add -Prelease or -Drelease to your release / deploy commands. this will also create proper distro in "dist" directory and upload it to maven repo. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150112/794b21db/attachment.html From stuart.w.douglas at gmail.com Mon Jan 12 21:47:43 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 13 Jan 2015 02:47:43 +0000 Subject: [wildfly-dev] Using Wildfly as a load balancer Message-ID: Hi everyone, A while ago we added support to Wildfly to allow it to be used as a front end mod_cluster based load balancer. I am going to blog about this once it appears in a released version, but for now if anyone wants to try it out I have an example in my github at https://github.com/stuartwdouglas/modcluster-example The example basically contains the CLI commands need to start a domain with two backend servers and a front end load balancer (with a simple deployment that prints the server name that handles the request, and can start counting requests to demonstrate sticky sessions and failover), although the deployment path and local IP address will need to be modified appropriately. I'm just posting about this here in case it is interesting to anyone, as it should provide a very simple way to get started with clustering. Stuart -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150113/ce9f9359/attachment.html From jorsol at gmail.com Mon Jan 12 22:35:26 2015 From: jorsol at gmail.com (=?ISO-8859-1?Q?Jorge_Sol=F3rzano?=) Date: Mon, 12 Jan 2015 21:35:26 -0600 Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: References: Message-ID: Hi Stuart, This means is no longer necessary to use Apache httpd as front end? What should be the pros and cont. when used like this? El ene 12, 2015 8:48 PM, "Stuart Douglas" escribi?: > Hi everyone, > > A while ago we added support to Wildfly to allow it to be used as a front > end mod_cluster based load balancer. > > I am going to blog about this once it appears in a released version, but > for now if anyone wants to try it out I have an example in my github at > https://github.com/stuartwdouglas/modcluster-example > > The example basically contains the CLI commands need to start a domain > with two backend servers and a front end load balancer (with a simple > deployment that prints the server name that handles the request, and can > start counting requests to demonstrate sticky sessions and failover), > although the deployment path and local IP address will need to be modified > appropriately. > > I'm just posting about this here in case it is interesting to anyone, as > it should provide a very simple way to get started with clustering. > > Stuart > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150112/30452d5f/attachment.html From stuart.w.douglas at gmail.com Mon Jan 12 23:55:33 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 13 Jan 2015 04:55:33 +0000 Subject: [wildfly-dev] Using Wildfly as a load balancer References: Message-ID: Yes, if you use this then it is no longer necessary to use apache as a load balancer. There are a few advantages to using Wildfly, namely: - Front and back end servers are all Wildfly, allowing them to all be managed uniformly through domain mode (which also means pure Java, so no native bits) - Undertow should be able to perform better than apache as a load balancer (although we don't have any firm benchmarks for this yet), and will be able to use new protocols such as HTTP2 to communicate with backend servers which are more efficient on the wire. The down side is of course that apache is already widely deployed, so a lot of organisations will already have experience with it, or be using apache for other things as well. Stuart On Tue Jan 13 2015 at 2:35:26 PM Jorge Sol?rzano wrote: > Hi Stuart, > > This means is no longer necessary to use Apache httpd as front end? What > should be the pros and cont. when used like this? > El ene 12, 2015 8:48 PM, "Stuart Douglas" > escribi?: > >> Hi everyone, >> >> A while ago we added support to Wildfly to allow it to be used as a front >> end mod_cluster based load balancer. >> >> I am going to blog about this once it appears in a released version, but >> for now if anyone wants to try it out I have an example in my github at >> https://github.com/stuartwdouglas/modcluster-example >> >> The example basically contains the CLI commands need to start a domain >> with two backend servers and a front end load balancer (with a simple >> deployment that prints the server name that handles the request, and can >> start counting requests to demonstrate sticky sessions and failover), >> although the deployment path and local IP address will need to be modified >> appropriately. >> >> I'm just posting about this here in case it is interesting to anyone, as >> it should provide a very simple way to get started with clustering. >> >> Stuart >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150113/958d9cde/attachment.html From valliantster at gmail.com Tue Jan 13 00:23:08 2015 From: valliantster at gmail.com (denstar) Date: Mon, 12 Jan 2015 22:23:08 -0700 Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: References: Message-ID: <54B4ABBC.2060408@gmail.com> On 01/12/2015 09:55 PM, Stuart Douglas wrote: > Yes, if you use this then it is no longer necessary to use apache as a load > balancer. This is fantastic news Stuart! I was just about to roll out something that bundles apache -- mostly for mod_cluster support, and URL rewriting -- and I'd prefer to go this route (ha!). I was going to ask about the latter-- that is, rewriting, but saw this: https://developer.jboss.org/thread/236258 Which I might give a go at, vs. tuckey... tho UrlRewriteFilter has some stuff for being able to consume apache-style rewrite rules, which kinda eases the minds of some potential transitioners, as it were. I haven't checked it in a while however, and it only covered a subset back then, which I kinda doubt has changed, so... *shrug* Anyways, I just wanted to take a second and give some kudos, and let you all know some random person is excited about this. Good timing! :Denny From brian.stansberry at redhat.com Tue Jan 13 09:54:05 2015 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Tue, 13 Jan 2015 08:54:05 -0600 Subject: [wildfly-dev] ALPN support In-Reply-To: References: <7506DFED-EFE6-4981-810D-52525B3F6973@redhat.com> Message-ID: <54B5318D.6090402@redhat.com> On 1/11/15 8:00 PM, Stuart Douglas wrote: > So I guess the real issue for domain mode is how we actually tell the > configured servers to use the ALPN jar, especially given that this > situation will likely be temporary, and not be required for Java 9+. > > One option could be that if the -alpn option is passed to the host > controller on boot then all servers that it spawns will also have alpn > on the boot class path, but that just seems really hacky. > The launcher stuff that James has done is meant to allow mirroring of our script behavior via a java API. So if we're adding stuff like this into the scripts it should go into the launcher too. Otherwise tools can't replicate script behavior. At least not without coding it up themselves. If it's in the launcher API it's not that hacky to pass the flag through to the HC process so it knows to use it. The whole thing is quite yuck though so (no offense meant) so I feel squeamish advocating putting it in the launcher API. > Another option would be to just require the user to setup the correct > -Xbootclasspath option manually in the JVM arguments. This is not very > user friendly though. > A third yuck option is to use RuntimeMXBean.getBootClassPath() and do hackery to identify "foreign" stuff, and then have the PC use that when creating the HC process and have the HC use it when creating server processes. But I like just having people configure it better. It's a pretty edgy case and it falls within the parameters of how a jvm config is meant to be used. I think the bigger question is whether this ends up in the launcher API. > Stuart > > On Wed Jan 07 2015 at 2:39:27 PM Jason T. Greene > > wrote: > > We should probably download these jars using a directory or file > name convention that is associated with the particular jvm version. > That way it becomes easy to support multiple jvm version > environments which is very common (both in domain and standalone). > > In domain mode we could have the host controller bootstrap follow > the same approach as standalone. For domain server configured jvms > we could reuse the logic as part of the JVM argument building process. > > On Jan 6, 2015, at 7:20 PM, Stuart Douglas > > wrote: > >> Hi all, >> Both SPDY and the upcoming HTTP2 protocol require the use of an >> SSL extension called ALPN (Application Layer Protocol >> Negotiation). Unfortunately this is not supported in current JDK's >> (it should appear in JDK9), so the only way to support these >> protocols in Java at the moment is to modify the boot class path >> and override the JDK SSL classes to add support for this. >> >> In practice this means add jetty-alpn-boot.jar to the boot class >> path, however the exact version of the jar that is required >> depends on the JVM version, which means we can't just ship a jar >> and add the boot class path stuff to our startup scripts. >> >> I have come up with a proof on concept[1] for how to deal with >> this, that will download the appropriate ALPN jar for the current >> server if -alpn is passed to the startup script, however we still >> need some way to handle this in domain mode, where we need to make >> sure the servers are all started with the appropriate parameter >> (worst case we could just require users to install the appropriate >> JAR themselves, and then set the appropriate JAVA_OPTS). >> >> Hopefully the need for this will go away with Java 9, so I am not >> sure how much effort we should spend dealing with this. >> >> Does anyone have any thoughts on this? >> >> Stuart >> >> [1] >> https://github.com/stuartwdouglas/wildfly-core/compare/wildfly:master...stuartwdouglas:alpn >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From stuart.w.douglas at gmail.com Tue Jan 13 18:01:27 2015 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Tue, 13 Jan 2015 23:01:27 +0000 Subject: [wildfly-dev] ALPN support References: <7506DFED-EFE6-4981-810D-52525B3F6973@redhat.com> <54B5318D.6090402@redhat.com> Message-ID: On Wed Jan 14 2015 at 1:54:34 AM Brian Stansberry < brian.stansberry at redhat.com> wrote: > On 1/11/15 8:00 PM, Stuart Douglas wrote: > > So I guess the real issue for domain mode is how we actually tell the > > configured servers to use the ALPN jar, especially given that this > > situation will likely be temporary, and not be required for Java 9+. > > > > One option could be that if the -alpn option is passed to the host > > controller on boot then all servers that it spawns will also have alpn > > on the boot class path, but that just seems really hacky. > > > > The launcher stuff that James has done is meant to allow mirroring of > our script behavior via a java API. So if we're adding stuff like this > into the scripts it should go into the launcher too. Otherwise tools > can't replicate script behavior. At least not without coding it up > themselves. > > If it's in the launcher API it's not that hacky to pass the flag through > to the HC process so it knows to use it. > > The whole thing is quite yuck though so (no offense meant) so I feel > squeamish advocating putting it in the launcher API. > Yea, this whole thing is really yuck. > > > Another option would be to just require the user to setup the correct > > -Xbootclasspath option manually in the JVM arguments. This is not very > > user friendly though. > > > > A third yuck option is to use RuntimeMXBean.getBootClassPath() and do > hackery to identify "foreign" stuff, and then have the PC use that when > creating the HC process and have the HC use it when creating server > processes. But I like just having people configure it better. It's a > pretty edgy case and it falls within the parameters of how a jvm config > is meant to be used. > I think the bigger question is whether this ends up in the launcher API. > I would rather it didn't, especially because this will hopefully all be unnecessary once Java 9 comes out. So now I am thinking we just document how to set this up, and once Java 9 is out and we support their new ALPN API we just require Java 9 for HTTP2 support. Stuart > > > Stuart > > > > On Wed Jan 07 2015 at 2:39:27 PM Jason T. Greene > > > wrote: > > > > We should probably download these jars using a directory or file > > name convention that is associated with the particular jvm version. > > That way it becomes easy to support multiple jvm version > > environments which is very common (both in domain and standalone). > > > > In domain mode we could have the host controller bootstrap follow > > the same approach as standalone. For domain server configured jvms > > we could reuse the logic as part of the JVM argument building > process. > > > > On Jan 6, 2015, at 7:20 PM, Stuart Douglas > > > > wrote: > > > >> Hi all, > >> Both SPDY and the upcoming HTTP2 protocol require the use of an > >> SSL extension called ALPN (Application Layer Protocol > >> Negotiation). Unfortunately this is not supported in current JDK's > >> (it should appear in JDK9), so the only way to support these > >> protocols in Java at the moment is to modify the boot class path > >> and override the JDK SSL classes to add support for this. > >> > >> In practice this means add jetty-alpn-boot.jar to the boot class > >> path, however the exact version of the jar that is required > >> depends on the JVM version, which means we can't just ship a jar > >> and add the boot class path stuff to our startup scripts. > >> > >> I have come up with a proof on concept[1] for how to deal with > >> this, that will download the appropriate ALPN jar for the current > >> server if -alpn is passed to the startup script, however we still > >> need some way to handle this in domain mode, where we need to make > >> sure the servers are all started with the appropriate parameter > >> (worst case we could just require users to install the appropriate > >> JAR themselves, and then set the appropriate JAVA_OPTS). > >> > >> Hopefully the need for this will go away with Java 9, so I am not > >> sure how much effort we should spend dealing with this. > >> > >> Does anyone have any thoughts on this? > >> > >> Stuart > >> > >> [1] > >> https://github.com/stuartwdouglas/wildfly-core/ > compare/wildfly:master...stuartwdouglas:alpn > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150113/2d819841/attachment-0001.html From jlivings at redhat.com Tue Jan 13 18:47:31 2015 From: jlivings at redhat.com (James Livingston) Date: Wed, 14 Jan 2015 09:47:31 +1000 Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: References: Message-ID: <1421192851.24451.29.camel@redhat.com> On Tue, 2015-01-13 at 04:55 +0000, Stuart Douglas wrote: > - Front and back end servers are all Wildfly, allowing them to all be > managed uniformly through domain mode (which also means pure Java, so no > native bits) Which also means you can use all Java tooling you know to work on problems, rather than C tooling which may be less familiar (and in some cases more difficult to do or less useful as well). Being able to use ByteMan to investigate what's happening in the load balancer rather than re-compiling a C module to add extra logging will be nice :) -- James "Doc" Livingston JBoss Support Engineering Group Red Hat From valliantster at gmail.com Tue Jan 13 23:31:09 2015 From: valliantster at gmail.com (denstar) Date: Tue, 13 Jan 2015 21:31:09 -0700 Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: <1421192851.24451.29.camel@redhat.com> References: <1421192851.24451.29.camel@redhat.com> Message-ID: <54B5F10D.1030008@gmail.com> On 01/13/2015 04:47 PM, James Livingston wrote: ... > Being able to use ByteMan to investigate what's happening in the load > balancer rather than re-compiling a C module to add extra logging will > be nice :) > For sure! Limitless possibilities. :) What would be the best way of restarting the load balancer itself? Maybe suggest say, a 2 node front-end, with X back-end nodes? :Denny From kabir.khan at jboss.com Wed Jan 14 03:39:26 2015 From: kabir.khan at jboss.com (Kabir Khan) Date: Wed, 14 Jan 2015 09:39:26 +0100 Subject: [wildfly-dev] ALPN support In-Reply-To: References: <7506DFED-EFE6-4981-810D-52525B3F6973@redhat.com> <54B5318D.6090402@redhat.com> Message-ID: > On 14 Jan 2015, at 00:01, Stuart Douglas wrote: > > > > On Wed Jan 14 2015 at 1:54:34 AM Brian Stansberry wrote: > On 1/11/15 8:00 PM, Stuart Douglas wrote: > > So I guess the real issue for domain mode is how we actually tell the > > configured servers to use the ALPN jar, especially given that this > > situation will likely be temporary, and not be required for Java 9+. > > > > One option could be that if the -alpn option is passed to the host > > controller on boot then all servers that it spawns will also have alpn > > on the boot class path, but that just seems really hacky. > > > > The launcher stuff that James has done is meant to allow mirroring of > our script behavior via a java API. So if we're adding stuff like this > into the scripts it should go into the launcher too. Otherwise tools > can't replicate script behavior. At least not without coding it up > themselves. > > If it's in the launcher API it's not that hacky to pass the flag through > to the HC process so it knows to use it. > > The whole thing is quite yuck though so (no offense meant) so I feel > squeamish advocating putting it in the launcher API. > > Yea, this whole thing is really yuck. > > > > Another option would be to just require the user to setup the correct > > -Xbootclasspath option manually in the JVM arguments. This is not very > > user friendly though. > > > > A third yuck option is to use RuntimeMXBean.getBootClassPath() and do > hackery to identify "foreign" stuff, and then have the PC use that when > creating the HC process and have the HC use it when creating server > processes. But I like just having people configure it better. It's a > pretty edgy case and it falls within the parameters of how a jvm config > is meant to be used. > > I think the bigger question is whether this ends up in the launcher API. > > I would rather it didn't, especially because this will hopefully all be unnecessary once Java 9 comes out. > > So now I am thinking we just document how to set this up, and once Java 9 is out and we support their new ALPN API we just require Java 9 for HTTP2 support. Or add it to the launcher API but deprecate the methods to do so right away? > > Stuart > > > > Stuart > > > > On Wed Jan 07 2015 at 2:39:27 PM Jason T. Greene > > > wrote: > > > > We should probably download these jars using a directory or file > > name convention that is associated with the particular jvm version. > > That way it becomes easy to support multiple jvm version > > environments which is very common (both in domain and standalone). > > > > In domain mode we could have the host controller bootstrap follow > > the same approach as standalone. For domain server configured jvms > > we could reuse the logic as part of the JVM argument building process. > > > > On Jan 6, 2015, at 7:20 PM, Stuart Douglas > > > wrote: > > > >> Hi all, > >> Both SPDY and the upcoming HTTP2 protocol require the use of an > >> SSL extension called ALPN (Application Layer Protocol > >> Negotiation). Unfortunately this is not supported in current JDK's > >> (it should appear in JDK9), so the only way to support these > >> protocols in Java at the moment is to modify the boot class path > >> and override the JDK SSL classes to add support for this. > >> > >> In practice this means add jetty-alpn-boot.jar to the boot class > >> path, however the exact version of the jar that is required > >> depends on the JVM version, which means we can't just ship a jar > >> and add the boot class path stuff to our startup scripts. > >> > >> I have come up with a proof on concept[1] for how to deal with > >> this, that will download the appropriate ALPN jar for the current > >> server if -alpn is passed to the startup script, however we still > >> need some way to handle this in domain mode, where we need to make > >> sure the servers are all started with the appropriate parameter > >> (worst case we could just require users to install the appropriate > >> JAR themselves, and then set the appropriate JAVA_OPTS). > >> > >> Hopefully the need for this will go away with Java 9, so I am not > >> sure how much effort we should spend dealing with this. > >> > >> Does anyone have any thoughts on this? > >> > >> Stuart > >> > >> [1] > >> https://github.com/stuartwdouglas/wildfly-core/compare/wildfly:master...stuartwdouglas:alpn > >> _______________________________________________ > >> 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 > _______________________________________________ > 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 Jan 16 08:30:17 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 16 Jan 2015 13:30:17 +0000 Subject: [wildfly-dev] Early Access builds for JDK 9 b45, JDK 8u40 b21 & JDK 7u80 b04 are available on java.net Message-ID: <54B91269.1060501@oracle.com> Hi Jason/Tomaz, Now that JDK 9 Early Access build images are modular [1], there is a fresh Early Access build for JDK 9 b45 available on java.net. The summary of changes are listed here In addition, there are new Early Access builds for the ongoing update releases. The Early Access build for JDK 8u40 b21 is available on java.net, with the summary of changes listed here. Finally, the Early Access build for JDK 7u80 b04 is available on java.net, with the summary of changes listed here. As we enter the later phases of development for JDK 7u80 & JDK 8u40, please log any show stoppers as soon as possible. Rgds,Rory [1] http://mreinhold.org/blog/jigsaw-modular-images -- 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/20150116/6ea731c2/attachment.html From filipepferraz at gmail.com Fri Jan 16 12:30:20 2015 From: filipepferraz at gmail.com (filipepferraz) Date: Fri, 16 Jan 2015 10:30:20 -0700 (MST) Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: References: Message-ID: <1421429420006-5715477.post@n5.nabble.com> Stuart, what version of wildfly can be used for test the cluster? I tried in 9.0.0.Alpha2-SNAPSHOT but don't find the mod-cluster filter inside the configuration=filter. -- View this message in context: http://wildfly-development.1055759.n5.nabble.com/Using-Wildfly-as-a-load-balancer-tp5715464p5715477.html Sent from the WildFly Development mailing list archive at Nabble.com. From tomaz.cerar at gmail.com Fri Jan 16 15:02:20 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 16 Jan 2015 21:02:20 +0100 Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: <1421429420006-5715477.post@n5.nabble.com> References: <1421429420006-5715477.post@n5.nabble.com> Message-ID: Take a look at demo Stuart prepared http://blog.eisele.net/2015/01/developer-interview-di-11-stuart-douglas-about-wildfly9-undertow.html On Fri, Jan 16, 2015 at 6:30 PM, filipepferraz wrote: > Stuart, what version of wildfly can be used for test the cluster? > I tried in 9.0.0.Alpha2-SNAPSHOT but don't find the mod-cluster filter > inside the configuration=filter. > > > > -- > View this message in context: > http://wildfly-development.1055759.n5.nabble.com/Using-Wildfly-as-a-load-balancer-tp5715464p5715477.html > Sent from the WildFly Development mailing list archive at Nabble.com. > _______________________________________________ > 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/20150116/3947e36d/attachment.html From valliantster at gmail.com Fri Jan 16 17:08:10 2015 From: valliantster at gmail.com (denstar) Date: Fri, 16 Jan 2015 15:08:10 -0700 Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: References: <1421429420006-5715477.post@n5.nabble.com> Message-ID: With something this new you'll probably be wanting to build from source or use a nightly. https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/ On Fri, Jan 16, 2015 at 1:02 PM, Toma? Cerar wrote: > Take a look at demo Stuart prepared > > http://blog.eisele.net/2015/01/developer-interview-di-11-stuart-douglas-about-wildfly9-undertow.html > > On Fri, Jan 16, 2015 at 6:30 PM, filipepferraz > wrote: > >> Stuart, what version of wildfly can be used for test the cluster? >> I tried in 9.0.0.Alpha2-SNAPSHOT but don't find the mod-cluster filter >> inside the configuration=filter. >> >> >> >> -- >> View this message in context: >> http://wildfly-development.1055759.n5.nabble.com/Using-Wildfly-as-a-load-balancer-tp5715464p5715477.html >> Sent from the WildFly Development mailing list archive at Nabble.com. >> _______________________________________________ >> 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/20150116/3d6065f4/attachment-0001.html From jorsol at gmail.com Fri Jan 16 17:34:43 2015 From: jorsol at gmail.com (=?ISO-8859-1?Q?Jorge_Sol=F3rzano?=) Date: Fri, 16 Jan 2015 16:34:43 -0600 Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: References: <1421429420006-5715477.post@n5.nabble.com> Message-ID: Hi Stuart, How will be handled the bind to low ports? will be needed to run the load-balancer as root or some user with privilege to bind in 80 or 443? Jorge Sol?rzano http://www.jorsol.com On Fri, Jan 16, 2015 at 4:08 PM, denstar wrote: > With something this new you'll probably be wanting to build from source or > use a nightly. > > https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/ > > On Fri, Jan 16, 2015 at 1:02 PM, Toma? Cerar > wrote: > >> Take a look at demo Stuart prepared >> >> http://blog.eisele.net/2015/01/developer-interview-di-11-stuart-douglas-about-wildfly9-undertow.html >> >> On Fri, Jan 16, 2015 at 6:30 PM, filipepferraz >> wrote: >> >>> Stuart, what version of wildfly can be used for test the cluster? >>> I tried in 9.0.0.Alpha2-SNAPSHOT but don't find the mod-cluster filter >>> inside the configuration=filter. >>> >>> >>> >>> -- >>> View this message in context: >>> http://wildfly-development.1055759.n5.nabble.com/Using-Wildfly-as-a-load-balancer-tp5715464p5715477.html >>> Sent from the WildFly Development mailing list archive at Nabble.com. >>> _______________________________________________ >>> 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/20150116/c1b2e9bf/attachment.html From valliantster at gmail.com Fri Jan 16 18:01:30 2015 From: valliantster at gmail.com (denstar) Date: Fri, 16 Jan 2015 16:01:30 -0700 Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: References: <1421429420006-5715477.post@n5.nabble.com> Message-ID: <54B9984A.1040308@gmail.com> On 01/16/2015 03:34 PM, Jorge Sol?rzano wrote: > Hi Stuart, > > How will be handled the bind to low ports? will be needed to run the > load-balancer as root or some user with privilege to bind in 80 or 443? Running as root is generally to be avoided. You could use software defined networking to do it (depending on your stack) and have some failover and whatnot there, as a bonus. Or use PF/iptables or something to forward from 80 to one above 1024. Search for "privileged port binding" + whatever system you're trying to do it on to find more information. Thanks for sharing that video Toma?, good stuff! :den From jason.greene at redhat.com Fri Jan 16 18:19:31 2015 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 16 Jan 2015 17:19:31 -0600 Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: References: <1421429420006-5715477.post@n5.nabble.com> Message-ID: <7EF1C6CE-7818-467F-BE59-B2668C658429@redhat.com> > On Jan 16, 2015, at 4:34 PM, Jorge Sol?rzano wrote: > > Hi Stuart, > > How will be handled the bind to low ports? will be needed to run the load-balancer as root or some user with privilege to bind in 80 or 443? What OS? Assuming Linux there are options, and I recommend A) unless you care about the minuscule CPU cycles spent in kernel netfilter code spent rewriting the packet: A. iptables rule or firewalld rule sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080 -or if you use firewalld- sudo firewall-cmd --add-forward-port=port=80:proto=tcp:toport=8080 --permanent B. Using setcap to grant perms for java to bind lower ports: sudo setcap cap_net_bind_service=+epi $JAVA_HOME/bin/java sudo setcap cap_net_bind_service=+epi $JAVA_HOME/jre/bin/java If you get an error about libjli.so, you will need to add it to an ld config: sudo echo $JAVA_HOME/jre/lib/amd64/jli/libjli.so > /etc/ld.so.conf.d/libjli.conf sudo ldconfig | grep libjli This should return: libjli.so -> libjli.so -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From valliantster at gmail.com Fri Jan 16 18:37:47 2015 From: valliantster at gmail.com (denstar) Date: Fri, 16 Jan 2015 16:37:47 -0700 Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: <7EF1C6CE-7818-467F-BE59-B2668C658429@redhat.com> References: <1421429420006-5715477.post@n5.nabble.com> <7EF1C6CE-7818-467F-BE59-B2668C658429@redhat.com> Message-ID: <54B9A0CB.30501@gmail.com> On 01/16/2015 04:19 PM, Jason Greene wrote: ... [snip helpful example rules] > > B. Using setcap to grant perms for java to bind lower ports: FWIW, this would open things up for Java in general, so while it should perform better, it'll also be a little more risky, which may or may not be a concern. > If you get an error about libjli.so, you will need to add it to an ld config: > > sudo echo $JAVA_HOME/jre/lib/amd64/jli/libjli.so > /etc/ld.so.conf.d/libjli.conf > sudo ldconfig | grep libjli > > This should return: > libjli.so -> libjli.so Good to know! -den From jason.greene at redhat.com Fri Jan 16 22:31:53 2015 From: jason.greene at redhat.com (Jason T. Greene) Date: Fri, 16 Jan 2015 22:31:53 -0500 (EST) Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: <54B9A0CB.30501@gmail.com> References: <1421429420006-5715477.post@n5.nabble.com> <7EF1C6CE-7818-467F-BE59-B2668C658429@redhat.com> <54B9A0CB.30501@gmail.com> Message-ID: <01BCDB57-7852-4954-98BB-E51F3988D2E9@redhat.com> > On Jan 16, 2015, at 5:37 PM, denstar wrote: > > On 01/16/2015 04:19 PM, Jason Greene wrote: > ... > [snip helpful example rules] >> >> B. Using setcap to grant perms for java to bind lower ports: > > FWIW, this would open things up for Java in general, so while it should > perform better, it'll also be a little more risky, which may or may not > be a concern. Right all Java code using this JVM would have access to binding *all ports* (e.g a Java program could bind say the ssh port (assuming it's not running) and sniff passwords). So it would be a good idea to have a dedicated JVM just for WildFly and to limit the execution permission to just a dedicated WildFly user. That way you ensure only the wildfly process can bind these ports. Alternatively, you could use something like docker which automates capability assignment and provides some extra isolation. It's overkill though if the only thing running on a box is a wildfly process. Just a note that you will still get fantastic performance with iptables port forwarding since the particular rule is completely stateless, and the action is just to modify the packet in memory. It's only extreme scenarios where that overhead is worth avoiding. -Jason From jorsol at gmail.com Sat Jan 17 09:27:22 2015 From: jorsol at gmail.com (=?ISO-8859-1?Q?Jorge_Sol=F3rzano?=) Date: Sat, 17 Jan 2015 08:27:22 -0600 Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: <01BCDB57-7852-4954-98BB-E51F3988D2E9@redhat.com> References: <1421429420006-5715477.post@n5.nabble.com> <7EF1C6CE-7818-467F-BE59-B2668C658429@redhat.com> <54B9A0CB.30501@gmail.com> <01BCDB57-7852-4954-98BB-E51F3988D2E9@redhat.com> Message-ID: Is authbind or privbind a good alternative? it probably has the same effect of setcap but with a little more security. It seems the best choice is iptables. Jorge Sol?rzano http://www.jorsol.com On Fri, Jan 16, 2015 at 9:31 PM, Jason T. Greene wrote: > > > On Jan 16, 2015, at 5:37 PM, denstar wrote: > > > > On 01/16/2015 04:19 PM, Jason Greene wrote: > > ... > > [snip helpful example rules] > >> > >> B. Using setcap to grant perms for java to bind lower ports: > > > > FWIW, this would open things up for Java in general, so while it should > > perform better, it'll also be a little more risky, which may or may not > > be a concern. > > Right all Java code using this JVM would have access to binding *all > ports* (e.g a Java program could bind say the ssh port (assuming it's not > running) and sniff passwords). So it would be a good idea to have a > dedicated JVM just for WildFly and to limit the execution permission to > just a dedicated WildFly user. That way you ensure only the wildfly process > can bind these ports. > > Alternatively, you could use something like docker which automates > capability assignment and provides some extra isolation. It's overkill > though if the only thing running on a box is a wildfly process. > > Just a note that you will still get fantastic performance with iptables > port forwarding since the particular rule is completely stateless, and the > action is just to modify the packet in memory. It's only extreme scenarios > where that overhead is worth avoiding. > > -Jason > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150117/1c2e71d4/attachment.html From jason.greene at redhat.com Sat Jan 17 11:12:51 2015 From: jason.greene at redhat.com (Jason Greene) Date: Sat, 17 Jan 2015 10:12:51 -0600 Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: References: <1421429420006-5715477.post@n5.nabble.com> <7EF1C6CE-7818-467F-BE59-B2668C658429@redhat.com> <54B9A0CB.30501@gmail.com> <01BCDB57-7852-4954-98BB-E51F3988D2E9@redhat.com> Message-ID: <22ECB41A-88AD-452F-81FF-DE1AE3520370@redhat.com> Sure, that should work, but would require some hacking if you are using domain mode, since it launches JVMs for server process. You would probably need to create a fake ?java? which was a script which called authbind on the real java. > On Jan 17, 2015, at 8:27 AM, Jorge Sol?rzano wrote: > > Is authbind or privbind a good alternative? it probably has the same effect of setcap but with a little more security. > > It seems the best choice is iptables. > > > > Jorge Sol?rzano > http://www.jorsol.com > > On Fri, Jan 16, 2015 at 9:31 PM, Jason T. Greene wrote: > > > On Jan 16, 2015, at 5:37 PM, denstar wrote: > > > > On 01/16/2015 04:19 PM, Jason Greene wrote: > > ... > > [snip helpful example rules] > >> > >> B. Using setcap to grant perms for java to bind lower ports: > > > > FWIW, this would open things up for Java in general, so while it should > > perform better, it'll also be a little more risky, which may or may not > > be a concern. > > Right all Java code using this JVM would have access to binding *all ports* (e.g a Java program could bind say the ssh port (assuming it's not running) and sniff passwords). So it would be a good idea to have a dedicated JVM just for WildFly and to limit the execution permission to just a dedicated WildFly user. That way you ensure only the wildfly process can bind these ports. > > Alternatively, you could use something like docker which automates capability assignment and provides some extra isolation. It's overkill though if the only thing running on a box is a wildfly process. > > Just a note that you will still get fantastic performance with iptables port forwarding since the particular rule is completely stateless, and the action is just to modify the packet in memory. It's only extreme scenarios where that overhead is worth avoiding. > > -Jason > > > > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From valliantster at gmail.com Sat Jan 17 13:22:31 2015 From: valliantster at gmail.com (denstar) Date: Sat, 17 Jan 2015 11:22:31 -0700 Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: References: <1421429420006-5715477.post@n5.nabble.com> <7EF1C6CE-7818-467F-BE59-B2668C658429@redhat.com> <54B9A0CB.30501@gmail.com> <01BCDB57-7852-4954-98BB-E51F3988D2E9@redhat.com> Message-ID: <54BAA867.40301@gmail.com> On 01/17/2015 07:27 AM, Jorge Sol?rzano wrote: > Is authbind or privbind a good alternative? it probably has the same effect > of setcap but with a little more security. > > It seems the best choice is iptables. > In general, probably. As Jason said, we're talking some pretty low-level optimization here. In 99% of cases it won't make a lick of difference performance-wise. Database calls and file reads and other IO will have a far more observable impact most the time, and are also more popular vectors of attack. It's more likely for one to have something dumb in their code opening a hole than say, the SSH port binding example given earlier-- tho the former leads to the latter, so +1 for layers. (Including code reviews and such.) Really it depends on what you're doing, and plan on doing in the future. Things vary by OS, which is something to consider if you're going to have end-users running your application servers, but not so much if you're offering a service, for example, or are fine specifying OS requirements and what have you. Den* From rstryker at redhat.com Mon Jan 19 02:44:57 2015 From: rstryker at redhat.com (Rob Stryker) Date: Mon, 19 Jan 2015 15:44:57 +0800 Subject: [wildfly-dev] What repo is jboss-deployment-structure-1_0.xsd in? Message-ID: <54BCB5F9.2030506@redhat.com> I've done a grep on the wildfly repo as well as the metadata repo, but can't locate this xsd's source. All results are in a /target/ folder, which (I assume) means it was brought in from elsewhere. [rob at rawbdor jboss_stuff]$ du -a | grep "jboss-deployment-structure-1_0.xsd" 28 ./wildfly/testsuite/integration/target/jbossas/docs/schema/jboss-deployment-structure-1_0.xsd 28 ./wildfly/testsuite/integration/smoke/target/jbossas/docs/schema/jboss-deployment-structure-1_0.xsd 28 ./wildfly/osgi/launcher/target/jbossas/docs/schema/jboss-deployment-structure-1_0.xsd 28 ./wildfly/dist/target/wildfly-9.0.0.Alpha1-SNAPSHOT/docs/schema/jboss-deployment-structure-1_0.xsd 28 ./wildfly/arquillian/container-embedded/target/jbossas/docs/schema/jboss-deployment-structure-1_0.xsd 28 ./wildfly/arquillian/container-managed-domain/target/jbossas/docs/schema/jboss-deployment-structure-1_0.xsd 28 ./wildfly/arquillian/testng-integration/target/jbossas/docs/schema/jboss-deployment-structure-1_0.xsd 28 ./wildfly/arquillian/container-managed/target/jbossas/docs/schema/jboss-deployment-structure-1_0.xsd Question is due to a bug in the schema for which I'd like to make a PR for. Specifically, - + Also, did we figure out a process for how and when to ensure the schema at http://www.jboss.org/schema/jbossas are updated after changes to their various repositories? ie, if my PR to jboss-deployment-structure-1_0.xsd is accepted, how long will it take for the website urls to be updated? - Rob Stryker From jmesnil at redhat.com Mon Jan 19 03:30:19 2015 From: jmesnil at redhat.com (Jeff Mesnil) Date: Mon, 19 Jan 2015 09:30:19 +0100 Subject: [wildfly-dev] What repo is jboss-deployment-structure-1_0.xsd in? In-Reply-To: <54BCB5F9.2030506@redhat.com> References: <54BCB5F9.2030506@redhat.com> Message-ID: <06549031-7745-4426-8D59-7ADEDC5F022C@redhat.com> > On 19 Jan 2015, at 08:44, Rob Stryker wrote: > > I've done a grep on the wildfly repo as well as the metadata repo, but > can't locate this xsd's source. All results are in a /target/ folder, > which (I assume) means it was brought in from elsewhere. It has been moved to wildfly-core: https://github.com/wildfly/wildfly-core/blob/master/server/src/main/resources/schema/jboss-deployment-structure-1_0.xsd jeff -- Jeff Mesnil JBoss, a division of Red Hat http://jmesnil.net/ From jcosta at redhat.com Mon Jan 19 05:05:38 2015 From: jcosta at redhat.com (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=) Date: Mon, 19 Jan 2015 11:05:38 +0100 Subject: [wildfly-dev] Using Wildfly as a load balancer In-Reply-To: <01BCDB57-7852-4954-98BB-E51F3988D2E9@redhat.com> References: <1421429420006-5715477.post@n5.nabble.com> <7EF1C6CE-7818-467F-BE59-B2668C658429@redhat.com> <54B9A0CB.30501@gmail.com> <01BCDB57-7852-4954-98BB-E51F3988D2E9@redhat.com> Message-ID: <54BCD6F2.8000903@redhat.com> On 01/17/2015 04:31 AM, Jason T. Greene wrote: > Right all Java code using this JVM would have access to binding *all ports* (e.g a Java program could bind say the ssh port (assuming it's not running) and sniff passwords). So it would be a good idea to have a dedicated JVM just for WildFly and to limit the execution permission to just a dedicated WildFly user. That way you ensure only the wildfly process can bind these ports. I guess selinux could help on this scenario. IIRC, selinux blocks WildFly (the one from the repos) from binding on non default ports (8080, ...), so, a custom rule to allow it to bind to 80 would be enough. If WildFly tries to bind to 22, selinux will block. - Juca. From pfestoso at redhat.com Fri Jan 23 12:18:10 2015 From: pfestoso at redhat.com (Phil Festoso) Date: Fri, 23 Jan 2015 12:18:10 -0500 (EST) Subject: [wildfly-dev] WF 8 vs EAP 6 and use of -b In-Reply-To: <538123096.14276121.1422033151907.JavaMail.zimbra@redhat.com> Message-ID: <2077578777.14278983.1422033490629.JavaMail.zimbra@redhat.com> Hi all, One of the changes from EAP 5 to 6 is that the -b option no longer "just works" and requires the admin to change the configuration to use instead of . Some of my customers were surprised by the change. They enjoyed the ease of use that -b gave them and are hoping to see that feature brought back. I noticed that in WF 8.2 -b does just work (at least on the RHEL vms I tested). Does this mean that users can expect to see -b back in play (ie w/o need for config changes) for EAP 7? Thanks. Phil Festoso Sr. Technical Account Manager, Global Support Services Red Hat, Inc. T: 312.612.0035 E: philfest at redhat.com From jason.greene at redhat.com Fri Jan 23 12:27:21 2015 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 23 Jan 2015 11:27:21 -0600 Subject: [wildfly-dev] WF 8 vs EAP 6 and use of -b In-Reply-To: <2077578777.14278983.1422033490629.JavaMail.zimbra@redhat.com> References: <2077578777.14278983.1422033490629.JavaMail.zimbra@redhat.com> Message-ID: Huh? -b does work, and the default is now loopback. The only thing that is really different is that we have a -b for the application ports and a -bmanagement for management ports. > On Jan 23, 2015, at 11:18 AM, Phil Festoso wrote: > > Hi all, > > One of the changes from EAP 5 to 6 is that the -b option no longer "just works" and requires the admin to change the configuration to use instead of . > > > Some of my customers were surprised by the change. They enjoyed the ease of use that -b gave them and are hoping to see that feature brought back. I noticed that in WF 8.2 -b does just work (at least on the RHEL vms I tested). Does this mean that users can expect to see -b back in play (ie w/o need for config changes) for EAP 7? > > Thanks. > > Phil Festoso > Sr. Technical Account Manager, Global Support Services > Red Hat, Inc. > T: 312.612.0035 > E: philfest at redhat.com > > _______________________________________________ > 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 Fri Jan 23 12:28:31 2015 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 23 Jan 2015 11:28:31 -0600 Subject: [wildfly-dev] WF 8 vs EAP 6 and use of -b In-Reply-To: References: <2077578777.14278983.1422033490629.JavaMail.zimbra@redhat.com> Message-ID: I mean its been like that since AS 7.0.0. > On Jan 23, 2015, at 11:27 AM, Jason Greene wrote: > > Huh? > > -b does work, and the default is now loopback. The only thing that is really different is that we have a -b for the application ports and a -bmanagement for management ports. > > >> On Jan 23, 2015, at 11:18 AM, Phil Festoso wrote: >> >> Hi all, >> >> One of the changes from EAP 5 to 6 is that the -b option no longer "just works" and requires the admin to change the configuration to use instead of . >> >> >> Some of my customers were surprised by the change. They enjoyed the ease of use that -b gave them and are hoping to see that feature brought back. I noticed that in WF 8.2 -b does just work (at least on the RHEL vms I tested). Does this mean that users can expect to see -b back in play (ie w/o need for config changes) for EAP 7? >> >> Thanks. >> >> Phil Festoso >> Sr. Technical Account Manager, Global Support Services >> Red Hat, Inc. >> T: 312.612.0035 >> E: philfest at redhat.com >> >> _______________________________________________ >> 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 tomaz.cerar at gmail.com Fri Jan 23 12:28:57 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 23 Jan 2015 18:28:57 +0100 Subject: [wildfly-dev] WF 8 vs EAP 6 and use of -b In-Reply-To: References: <2077578777.14278983.1422033490629.JavaMail.zimbra@redhat.com> Message-ID: Maybe this is a problem on some specific OS / JVM combination? As for most of the cases we know of it works. On Fri, Jan 23, 2015 at 6:27 PM, Jason Greene wrote: > Huh? > > -b does work, and the default is now loopback. The only thing that is > really different is that we have a -b for the application ports and a > -bmanagement for management ports. > > > > On Jan 23, 2015, at 11:18 AM, Phil Festoso wrote: > > > > Hi all, > > > > One of the changes from EAP 5 to 6 is that the -b option no longer "just > works" and requires the admin to change the configuration to use > instead of . > > > > > > Some of my customers were surprised by the change. They enjoyed the ease > of use that -b gave them and are hoping to see that feature brought back. I > noticed that in WF 8.2 -b does just work (at least on the RHEL vms I > tested). Does this mean that users can expect to see -b back in play (ie > w/o need for config changes) for EAP 7? > > > > Thanks. > > > > Phil Festoso > > Sr. Technical Account Manager, Global Support Services > > Red Hat, Inc. > > T: 312.612.0035 > > E: philfest at redhat.com > > > > _______________________________________________ > > 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/20150123/57987500/attachment.html From jason.greene at redhat.com Fri Jan 23 12:32:42 2015 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 23 Jan 2015 11:32:42 -0600 Subject: [wildfly-dev] WF 8 vs EAP 6 and use of -b In-Reply-To: References: <2077578777.14278983.1422033490629.JavaMail.zimbra@redhat.com> Message-ID: <15A54736-AA86-461B-9F27-F97A6687C786@redhat.com> Well our configuration for all releases of AS7, EAP and WildFly specifies: So unless 127.0.0.1 was somehow bound to a non-loopback interface I don?t think that is even possible. > On Jan 23, 2015, at 11:28 AM, Toma? Cerar wrote: > > Maybe this is a problem on some specific OS / JVM combination? > > As for most of the cases we know of it works. > > > On Fri, Jan 23, 2015 at 6:27 PM, Jason Greene wrote: > Huh? > > -b does work, and the default is now loopback. The only thing that is really different is that we have a -b for the application ports and a -bmanagement for management ports. > > > > On Jan 23, 2015, at 11:18 AM, Phil Festoso wrote: > > > > Hi all, > > > > One of the changes from EAP 5 to 6 is that the -b option no longer "just works" and requires the admin to change the configuration to use instead of . > > > > > > Some of my customers were surprised by the change. They enjoyed the ease of use that -b gave them and are hoping to see that feature brought back. I noticed that in WF 8.2 -b does just work (at least on the RHEL vms I tested). Does this mean that users can expect to see -b back in play (ie w/o need for config changes) for EAP 7? > > > > Thanks. > > > > Phil Festoso > > Sr. Technical Account Manager, Global Support Services > > Red Hat, Inc. > > T: 312.612.0035 > > E: philfest at redhat.com > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From tomaz.cerar at gmail.com Fri Jan 23 12:44:45 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Fri, 23 Jan 2015 18:44:45 +0100 Subject: [wildfly-dev] WF 8 vs EAP 6 and use of -b In-Reply-To: <15A54736-AA86-461B-9F27-F97A6687C786@redhat.com> References: <2077578777.14278983.1422033490629.JavaMail.zimbra@redhat.com> <15A54736-AA86-461B-9F27-F97A6687C786@redhat.com> Message-ID: Just mentioned it as in mac osx when you start standalone-ha.xml with -b 0.0.0.0 jgroups complains about not being able to bind and you get some ugly warning / error. On Fri, Jan 23, 2015 at 6:32 PM, Jason Greene wrote: > Well our configuration for all releases of AS7, EAP and WildFly specifies: > > > > > > So unless 127.0.0.1 was somehow bound to a non-loopback interface I don?t > think that is even possible. > > > On Jan 23, 2015, at 11:28 AM, Toma? Cerar wrote: > > > > Maybe this is a problem on some specific OS / JVM combination? > > > > As for most of the cases we know of it works. > > > > > > On Fri, Jan 23, 2015 at 6:27 PM, Jason Greene > wrote: > > Huh? > > > > -b does work, and the default is now loopback. The only thing that is > really different is that we have a -b for the application ports and a > -bmanagement for management ports. > > > > > > > On Jan 23, 2015, at 11:18 AM, Phil Festoso > wrote: > > > > > > Hi all, > > > > > > One of the changes from EAP 5 to 6 is that the -b option no longer > "just works" and requires the admin to change the configuration to use > instead of . > > > > > > > > > Some of my customers were surprised by the change. They enjoyed the > ease of use that -b gave them and are hoping to see that feature brought > back. I noticed that in WF 8.2 -b does just work (at least on the RHEL vms > I tested). Does this mean that users can expect to see -b back in play (ie > w/o need for config changes) for EAP 7? > > > > > > Thanks. > > > > > > Phil Festoso > > > Sr. Technical Account Manager, Global Support Services > > > Red Hat, Inc. > > > T: 312.612.0035 > > > E: philfest at redhat.com > > > > > > _______________________________________________ > > > wildfly-dev mailing list > > > wildfly-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > > Jason T. Greene > > WildFly Lead / JBoss EAP Platform Architect > > JBoss, a division of Red Hat > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150123/aee35e37/attachment.html From pfestoso at redhat.com Fri Jan 23 12:49:08 2015 From: pfestoso at redhat.com (Phil Festoso) Date: Fri, 23 Jan 2015 12:49:08 -0500 (EST) Subject: [wildfly-dev] WF 8 vs EAP 6 and use of -b In-Reply-To: <15A54736-AA86-461B-9F27-F97A6687C786@redhat.com> References: <2077578777.14278983.1422033490629.JavaMail.zimbra@redhat.com> <15A54736-AA86-461B-9F27-F97A6687C786@redhat.com> Message-ID: <1370572527.14291381.1422035348283.JavaMail.zimbra@redhat.com> More context is needed. Apologies. In EAP 6, I'm restricted to the known loopback address. So, if I try -b 127.0.1.1, the service won't start without adding an alias to the lo interface. In WF 8.2 I've had success using anything under 127.0.*.* without the need for an alias. This is true for RHEL 6.5 and 7 with oracle jdk 1.7_71, and does not work on my win 7 pc at home, so there might be something to the notion that this behavior is dependent on JDK/OS pairings. Hope that clarifies things. Thanks for the responses. ----- Original Message ----- From: "Jason Greene" To: "Toma? Cerar" Cc: "Phil Festoso" , wildfly-dev at lists.jboss.org Sent: Friday, January 23, 2015 11:32:42 AM Subject: Re: [wildfly-dev] WF 8 vs EAP 6 and use of -b Well our configuration for all releases of AS7, EAP and WildFly specifies: So unless 127.0.0.1 was somehow bound to a non-loopback interface I don?t think that is even possible. > On Jan 23, 2015, at 11:28 AM, Toma? Cerar wrote: > > Maybe this is a problem on some specific OS / JVM combination? > > As for most of the cases we know of it works. > > > On Fri, Jan 23, 2015 at 6:27 PM, Jason Greene wrote: > Huh? > > -b does work, and the default is now loopback. The only thing that is really different is that we have a -b for the application ports and a -bmanagement for management ports. > > > > On Jan 23, 2015, at 11:18 AM, Phil Festoso wrote: > > > > Hi all, > > > > One of the changes from EAP 5 to 6 is that the -b option no longer "just works" and requires the admin to change the configuration to use instead of . > > > > > > Some of my customers were surprised by the change. They enjoyed the ease of use that -b gave them and are hoping to see that feature brought back. I noticed that in WF 8.2 -b does just work (at least on the RHEL vms I tested). Does this mean that users can expect to see -b back in play (ie w/o need for config changes) for EAP 7? > > > > Thanks. > > > > Phil Festoso > > Sr. Technical Account Manager, Global Support Services > > Red Hat, Inc. > > T: 312.612.0035 > > E: philfest at redhat.com > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From jason.greene at redhat.com Fri Jan 23 12:53:58 2015 From: jason.greene at redhat.com (Jason Greene) Date: Fri, 23 Jan 2015 11:53:58 -0600 Subject: [wildfly-dev] WF 8 vs EAP 6 and use of -b In-Reply-To: <1370572527.14291381.1422035348283.JavaMail.zimbra@redhat.com> References: <2077578777.14278983.1422033490629.JavaMail.zimbra@redhat.com> <15A54736-AA86-461B-9F27-F97A6687C786@redhat.com> <1370572527.14291381.1422035348283.JavaMail.zimbra@redhat.com> Message-ID: <5687060A-CB29-4878-92CF-D1CF7D6F2577@redhat.com> Ah yes, originally we verified there was an interface available on the OS that was assigned that IP, but removed the validation code to make it more flexible for OSs which support dynamic loopback IPs (Linux). Windows does not support that concept which is why you saw it fail. > On Jan 23, 2015, at 11:49 AM, Phil Festoso wrote: > > More context is needed. Apologies. > > In EAP 6, I'm restricted to the known loopback address. So, if I try -b 127.0.1.1, the service won't start without adding an alias to the lo interface. In WF 8.2 I've had success using anything under 127.0.*.* without the need for an alias. This is true for RHEL 6.5 and 7 with oracle jdk 1.7_71, and does not work on my win 7 pc at home, so there might be something to the notion that this behavior is dependent on JDK/OS pairings. > > Hope that clarifies things. Thanks for the responses. > > ----- Original Message ----- > From: "Jason Greene" > To: "Toma? Cerar" > Cc: "Phil Festoso" , wildfly-dev at lists.jboss.org > Sent: Friday, January 23, 2015 11:32:42 AM > Subject: Re: [wildfly-dev] WF 8 vs EAP 6 and use of -b > > Well our configuration for all releases of AS7, EAP and WildFly specifies: > > > > > > So unless 127.0.0.1 was somehow bound to a non-loopback interface I don?t think that is even possible. > >> On Jan 23, 2015, at 11:28 AM, Toma? Cerar wrote: >> >> Maybe this is a problem on some specific OS / JVM combination? >> >> As for most of the cases we know of it works. >> >> >> On Fri, Jan 23, 2015 at 6:27 PM, Jason Greene wrote: >> Huh? >> >> -b does work, and the default is now loopback. The only thing that is really different is that we have a -b for the application ports and a -bmanagement for management ports. >> >> >>> On Jan 23, 2015, at 11:18 AM, Phil Festoso wrote: >>> >>> Hi all, >>> >>> One of the changes from EAP 5 to 6 is that the -b option no longer "just works" and requires the admin to change the configuration to use instead of . >>> >>> >>> Some of my customers were surprised by the change. They enjoyed the ease of use that -b gave them and are hoping to see that feature brought back. I noticed that in WF 8.2 -b does just work (at least on the RHEL vms I tested). Does this mean that users can expect to see -b back in play (ie w/o need for config changes) for EAP 7? >>> >>> Thanks. >>> >>> Phil Festoso >>> Sr. Technical Account Manager, Global Support Services >>> Red Hat, Inc. >>> T: 312.612.0035 >>> E: philfest at redhat.com >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > 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 pfestoso at redhat.com Fri Jan 23 13:38:44 2015 From: pfestoso at redhat.com (Phil Festoso) Date: Fri, 23 Jan 2015 13:38:44 -0500 (EST) Subject: [wildfly-dev] WF 8 vs EAP 6 and use of -b In-Reply-To: <5687060A-CB29-4878-92CF-D1CF7D6F2577@redhat.com> References: <2077578777.14278983.1422033490629.JavaMail.zimbra@redhat.com> <15A54736-AA86-461B-9F27-F97A6687C786@redhat.com> <1370572527.14291381.1422035348283.JavaMail.zimbra@redhat.com> <5687060A-CB29-4878-92CF-D1CF7D6F2577@redhat.com> Message-ID: <339735883.14321149.1422038324596.JavaMail.zimbra@redhat.com> Thanks for that. Will pass along to the cust. ----- Original Message ----- From: "Jason Greene" To: "Phil Festoso" Cc: wildfly-dev at lists.jboss.org Sent: Friday, January 23, 2015 11:53:58 AM Subject: Re: [wildfly-dev] WF 8 vs EAP 6 and use of -b Ah yes, originally we verified there was an interface available on the OS that was assigned that IP, but removed the validation code to make it more flexible for OSs which support dynamic loopback IPs (Linux). Windows does not support that concept which is why you saw it fail. > On Jan 23, 2015, at 11:49 AM, Phil Festoso wrote: > > More context is needed. Apologies. > > In EAP 6, I'm restricted to the known loopback address. So, if I try -b 127.0.1.1, the service won't start without adding an alias to the lo interface. In WF 8.2 I've had success using anything under 127.0.*.* without the need for an alias. This is true for RHEL 6.5 and 7 with oracle jdk 1.7_71, and does not work on my win 7 pc at home, so there might be something to the notion that this behavior is dependent on JDK/OS pairings. > > Hope that clarifies things. Thanks for the responses. > > ----- Original Message ----- > From: "Jason Greene" > To: "Toma? Cerar" > Cc: "Phil Festoso" , wildfly-dev at lists.jboss.org > Sent: Friday, January 23, 2015 11:32:42 AM > Subject: Re: [wildfly-dev] WF 8 vs EAP 6 and use of -b > > Well our configuration for all releases of AS7, EAP and WildFly specifies: > > > > > > So unless 127.0.0.1 was somehow bound to a non-loopback interface I don?t think that is even possible. > >> On Jan 23, 2015, at 11:28 AM, Toma? Cerar wrote: >> >> Maybe this is a problem on some specific OS / JVM combination? >> >> As for most of the cases we know of it works. >> >> >> On Fri, Jan 23, 2015 at 6:27 PM, Jason Greene wrote: >> Huh? >> >> -b does work, and the default is now loopback. The only thing that is really different is that we have a -b for the application ports and a -bmanagement for management ports. >> >> >>> On Jan 23, 2015, at 11:18 AM, Phil Festoso wrote: >>> >>> Hi all, >>> >>> One of the changes from EAP 5 to 6 is that the -b option no longer "just works" and requires the admin to change the configuration to use instead of . >>> >>> >>> Some of my customers were surprised by the change. They enjoyed the ease of use that -b gave them and are hoping to see that feature brought back. I noticed that in WF 8.2 -b does just work (at least on the RHEL vms I tested). Does this mean that users can expect to see -b back in play (ie w/o need for config changes) for EAP 7? >>> >>> Thanks. >>> >>> Phil Festoso >>> Sr. Technical Account Manager, Global Support Services >>> Red Hat, Inc. >>> T: 312.612.0035 >>> E: philfest at redhat.com >>> >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > 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 rsvoboda at redhat.com Fri Jan 23 15:31:32 2015 From: rsvoboda at redhat.com (Rostislav Svoboda) Date: Fri, 23 Jan 2015 15:31:32 -0500 (EST) Subject: [wildfly-dev] WF 8 vs EAP 6 and use of -b In-Reply-To: <5687060A-CB29-4878-92CF-D1CF7D6F2577@redhat.com> References: <2077578777.14278983.1422033490629.JavaMail.zimbra@redhat.com> <15A54736-AA86-461B-9F27-F97A6687C786@redhat.com> <1370572527.14291381.1422035348283.JavaMail.zimbra@redhat.com> <5687060A-CB29-4878-92CF-D1CF7D6F2577@redhat.com> Message-ID: <318750451.14275747.1422045092296.JavaMail.zimbra@redhat.com> https://issues.jboss.org/browse/WFLY-248 https://github.com/wildfly/wildfly/pull/4706 Rostislav ----- Original Message ----- > Ah yes, originally we verified there was an interface available on the OS > that was assigned that IP, but removed the validation code to make it more > flexible for OSs which support dynamic loopback IPs (Linux). Windows does > not support that concept which is why you saw it fail. > > > On Jan 23, 2015, at 11:49 AM, Phil Festoso wrote: > > > > More context is needed. Apologies. > > > > In EAP 6, I'm restricted to the known loopback address. So, if I try -b > > 127.0.1.1, the service won't start without adding an alias to the lo > > interface. In WF 8.2 I've had success using anything under 127.0.*.* > > without the need for an alias. This is true for RHEL 6.5 and 7 with oracle > > jdk 1.7_71, and does not work on my win 7 pc at home, so there might be > > something to the notion that this behavior is dependent on JDK/OS > > pairings. > > > > Hope that clarifies things. Thanks for the responses. > > > > ----- Original Message ----- > > From: "Jason Greene" > > To: "Toma? Cerar" > > Cc: "Phil Festoso" , wildfly-dev at lists.jboss.org > > Sent: Friday, January 23, 2015 11:32:42 AM > > Subject: Re: [wildfly-dev] WF 8 vs EAP 6 and use of -b > > > > Well our configuration for all releases of AS7, EAP and WildFly specifies: > > > > > > > > > > > > So unless 127.0.0.1 was somehow bound to a non-loopback interface I don?t > > think that is even possible. > > > >> On Jan 23, 2015, at 11:28 AM, Toma? Cerar wrote: > >> > >> Maybe this is a problem on some specific OS / JVM combination? > >> > >> As for most of the cases we know of it works. > >> > >> > >> On Fri, Jan 23, 2015 at 6:27 PM, Jason Greene > >> wrote: > >> Huh? > >> > >> -b does work, and the default is now loopback. The only thing that is > >> really different is that we have a -b for the application ports and a > >> -bmanagement for management ports. > >> > >> > >>> On Jan 23, 2015, at 11:18 AM, Phil Festoso wrote: > >>> > >>> Hi all, > >>> > >>> One of the changes from EAP 5 to 6 is that the -b option no longer "just > >>> works" and requires the admin to change the configuration to use > >>> instead of . > >>> > >>> > >>> Some of my customers were surprised by the change. They enjoyed the ease > >>> of use that -b gave them and are hoping to see that feature brought > >>> back. I noticed that in WF 8.2 -b does just work (at least on the RHEL > >>> vms I tested). Does this mean that users can expect to see -b back in > >>> play (ie w/o need for config changes) for EAP 7? > >>> > >>> Thanks. > >>> > >>> Phil Festoso > >>> Sr. Technical Account Manager, Global Support Services > >>> Red Hat, Inc. > >>> T: 312.612.0035 > >>> E: philfest at redhat.com > >>> > >>> _______________________________________________ > >>> wildfly-dev mailing list > >>> wildfly-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> -- > >> Jason T. Greene > >> WildFly Lead / JBoss EAP Platform Architect > >> JBoss, a division of Red Hat > >> > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > > > -- > > Jason T. Greene > > WildFly Lead / JBoss EAP Platform Architect > > JBoss, a division of Red Hat > > > > > > _______________________________________________ > > 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 sanne at hibernate.org Sun Jan 25 17:18:07 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Sun, 25 Jan 2015 22:18:07 +0000 Subject: [wildfly-dev] NPE in finalizer of ThreadPoolExecutor Message-ID: Hi all, I was investigating this issue which I believed initially to be a JDK bug, but it turns out it's caused by WildFly and I'm not really sure what problems it could cause. The symptom is a NullPointerException being thrown in the "Finalizer" Daemon System Thread, while attempting to shut down a ThreadPoolExecutor: Daemon System Thread [Finalizer] (Suspended (exception NullPointerException)) ThreadPoolExecutor.tryTerminate() line: 694 [local variables unavailable] ThreadPoolExecutor.shutdown() line: 1394 ThreadPoolExecutor.finalize() line: 1477 System$2.invokeFinalize(Object) line: 1267 Finalizer.runFinalizer(JavaLangAccess) line: 98 Finalizer.access$100(Finalizer, JavaLangAccess) line: 34 Finalizer$FinalizerThread.run() line: 210 That line 694 contains this line: (runStateOf(c) == SHUTDOWN && ! workQueue.isEmpty())) // NPE: workQueue==null The "workQueue" is final, and proper checks are in place in the constructor won't allow for it to be initialized with null. So I believe this is merely the "finalizer" being triggered for an instance of ThreadPoolExecutor which was not successfully constructed; indeed if I set a breakpoint on the "throw new IllegalArgumentException()" line of the constructor, this trips on a JMS/HornetQ related stack: Thread [ServerService Thread Pool -- 64] (Suspended (breakpoint at line 1307 in ThreadPoolExecutor)) owns: PostOfficeImpl (id=270) owns: HornetQServerImpl (id=271) owns: JMSServerManagerImpl (id=272) owns: JMSService (id=273) ThreadPoolExecutor.(int, int, long, TimeUnit, BlockingQueue, ThreadFactory, RejectedExecutionHandler) line: 1307 ThreadPoolExecutor.(int, int, long, TimeUnit, BlockingQueue) line: 1195 Executors.newFixedThreadPool(int) line: 89 UUIDGenerator.getHardwareAddress() line: 151 UUIDGenerator.getAddressBytes() line: 263 UUIDGenerator.generateStringUUID() line: 206 PostOfficeImpl.addBinding(Binding) line: 481 HornetQServerImpl.loadJournals() line: 1766 HornetQServerImpl.initialisePart2() line: 1593 HornetQServerImpl.access$1400(HornetQServerImpl) line: 178 HornetQServerImpl$SharedStoreLiveActivation.run() line: 2314 HornetQServerImpl.start() line: 435 JMSServerManagerImpl.start() line: 490 JMSService.doStart(StartContext) line: 155 JMSService.access$000(JMSService, StartContext) line: 60 JMSService$1.run() line: 94 Executors$RunnableAdapter.call() line: 511 FutureTask.run() line: 266 ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142 ThreadPoolExecutor$Worker.run() line: 617 JBossThread(Thread).run() line: 745 JBossThread.run() line: 122 This doesn't seem to be a real problem for the finalizer thread as it ignores any RuntimeException, and also not a problem for the Executor so I guess the puzzle is far less exciting than the subject of this email might have made you believe :-) But still it would be nice to avoid constructing an illegal Executor, and I have no idea if this could be a real problem for those UUID Generator services which I see in the stacktrace. In my integration test I was updating versions of libraries and application server to EAP 6.4.0.Alpha, but still using an old "standalone.xml" file. I guess the outdated configuration file might have fooled some validation. Thanks, Sanne From eduardo.santanadasilva at gmail.com Mon Jan 26 05:15:08 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Mon, 26 Jan 2015 08:15:08 -0200 Subject: [wildfly-dev] NPE in finalizer of ThreadPoolExecutor In-Reply-To: References: Message-ID: Hello, Could you provide more information? What is your OS, JVM, and WFLY versions? Which configuration file are you using to startup the server? Is there any sample app to reproduce your test? Tnanks Eduardo Sant'Ana da Silva 2015-01-25 20:18 GMT-02:00 Sanne Grinovero : > Hi all, > I was investigating this issue which I believed initially to be a JDK > bug, but it turns out it's caused by WildFly and I'm not really sure > what problems it could cause. > > The symptom is a NullPointerException being thrown in the "Finalizer" > Daemon System Thread, while attempting to shut down a > ThreadPoolExecutor: > > Daemon System Thread [Finalizer] (Suspended (exception > NullPointerException)) > ThreadPoolExecutor.tryTerminate() line: 694 [local variables unavailable] > ThreadPoolExecutor.shutdown() line: 1394 > ThreadPoolExecutor.finalize() line: 1477 > System$2.invokeFinalize(Object) line: 1267 > Finalizer.runFinalizer(JavaLangAccess) line: 98 > Finalizer.access$100(Finalizer, JavaLangAccess) line: 34 > Finalizer$FinalizerThread.run() line: 210 > > That line 694 contains this line: > (runStateOf(c) == SHUTDOWN && ! workQueue.isEmpty())) // NPE: > workQueue==null > > The "workQueue" is final, and proper checks are in place in the > constructor won't allow for it to be initialized with null. > So I believe this is merely the "finalizer" being triggered for an > instance of ThreadPoolExecutor which was not successfully constructed; > indeed if I set a breakpoint on the "throw new > IllegalArgumentException()" line of the constructor, this trips on a > JMS/HornetQ related stack: > > Thread [ServerService Thread Pool -- 64] (Suspended (breakpoint at > line 1307 in ThreadPoolExecutor)) > owns: PostOfficeImpl (id=270) > owns: HornetQServerImpl (id=271) > owns: JMSServerManagerImpl (id=272) > owns: JMSService (id=273) > ThreadPoolExecutor.(int, int, long, TimeUnit, > BlockingQueue, ThreadFactory, RejectedExecutionHandler) > line: 1307 > ThreadPoolExecutor.(int, int, long, TimeUnit, > BlockingQueue) line: 1195 > Executors.newFixedThreadPool(int) line: 89 > UUIDGenerator.getHardwareAddress() line: 151 > UUIDGenerator.getAddressBytes() line: 263 > UUIDGenerator.generateStringUUID() line: 206 > PostOfficeImpl.addBinding(Binding) line: 481 > HornetQServerImpl.loadJournals() line: 1766 > HornetQServerImpl.initialisePart2() line: 1593 > HornetQServerImpl.access$1400(HornetQServerImpl) line: 178 > HornetQServerImpl$SharedStoreLiveActivation.run() line: 2314 > HornetQServerImpl.start() line: 435 > JMSServerManagerImpl.start() line: 490 > JMSService.doStart(StartContext) line: 155 > JMSService.access$000(JMSService, StartContext) line: 60 > JMSService$1.run() line: 94 > Executors$RunnableAdapter.call() line: 511 > FutureTask.run() line: 266 > ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142 > ThreadPoolExecutor$Worker.run() line: 617 > JBossThread(Thread).run() line: 745 > JBossThread.run() line: 122 > > This doesn't seem to be a real problem for the finalizer thread as it > ignores any RuntimeException, and also not a problem for the Executor > so I guess the puzzle is far less exciting than the subject of this > email might have made you believe :-) > But still it would be nice to avoid constructing an illegal Executor, > and I have no idea if this could be a real problem for those UUID > Generator services which I see in the stacktrace. > > In my integration test I was updating versions of libraries and > application server to EAP 6.4.0.Alpha, but still using an old > "standalone.xml" file. I guess the outdated configuration file might > have fooled some validation. > > Thanks, > Sanne > _______________________________________________ > 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/20150126/cb3bdfed/attachment.html From rstryker at redhat.com Wed Jan 28 08:11:15 2015 From: rstryker at redhat.com (Rob Stryker) Date: Wed, 28 Jan 2015 21:11:15 +0800 Subject: [wildfly-dev] IP6 and Any known incompatibilities between these versions? Message-ID: <54C8DFF3.9050903@redhat.com> Hi all: JBT is considering updating the following client jar versions for communication with all wildfly streams 8.x over management api: marshalling from 1.4.3 to 1.4.9 remoting from 4.0.0 to 4.0.9 xnio from 3.2.0 to 3.3.0 protocol from 8.0.0 to 8.2.0.CR1 controller-client from 8.0.0 to 8.2.0.CR1 The cause for this is that when using the current jars, executing management tasks with ip6 hosts fails against all wf8.x servers. So far, updating the jars has passed our smoke tests. Two questions: 1) Are there any known incompatibilities for those new jar versions with any wf8.0 or higher? ie, should this new set of jars be able to communicate flawlessly with wf8.0 through 8.2? 2) This one's more of a curiousity, but does anyone know what caused the 8.0 jars to fail against all servers for management over ip6? I've combed through jira and git logs a bit but nothing really jumped out at me. Answers to these two questions would increase our confidence in bumping the jars more than simple smoke tests. - Rob Stryker From sanne at hibernate.org Wed Jan 28 10:21:50 2015 From: sanne at hibernate.org (Sanne Grinovero) Date: Wed, 28 Jan 2015 15:21:50 +0000 Subject: [wildfly-dev] NPE in finalizer of ThreadPoolExecutor In-Reply-To: References: Message-ID: On 26 January 2015 at 10:15, Eduardo Sant?Ana da Silva wrote: > Hello, > > Could you provide more information? > > > What is your OS, JVM, and WFLY versions? OS -> Linux (custom build, pure 64 bit) JVM -> OpenJDK 64-Bit 1.7.0_65 WFLY -> It's actually the preview of EAP 6.4 - as I say below ;-) - 6.4.0.Alpha I suspect the issue is caused by using an outdated configuration file, this is the one I was using: https://github.com/hibernate/hibernate-search/blob/4.4/integrationtest/as/src/as7config/standalone/configuration/standalone-securedjms.xml I guess one isn't supposed to use an outdated configuration file? I don't remember when I forked this configuration file, but it was probably before EAP 6.2, to make some changes necessary to the integration tests we run. The Arquillian based tests in that same module should be able to reproduce the issue, although you'd need to make some changes to upgrade dependencies to EAP 6.4 as that branch is using EAP 6.3. Unfortunately EAP 6.4 is not in Maven yet so I can't commit the version changes... but I suspect you'd have the same problem by using this old configuration file in latest WildFly? Thanks, Sanne > > Which configuration file are you using to startup the server? > > Is there any sample app to reproduce your test? > > > Tnanks > Eduardo Sant'Ana da Silva > > > 2015-01-25 20:18 GMT-02:00 Sanne Grinovero : >> >> Hi all, >> I was investigating this issue which I believed initially to be a JDK >> bug, but it turns out it's caused by WildFly and I'm not really sure >> what problems it could cause. >> >> The symptom is a NullPointerException being thrown in the "Finalizer" >> Daemon System Thread, while attempting to shut down a >> ThreadPoolExecutor: >> >> Daemon System Thread [Finalizer] (Suspended (exception >> NullPointerException)) >> ThreadPoolExecutor.tryTerminate() line: 694 [local variables unavailable] >> ThreadPoolExecutor.shutdown() line: 1394 >> ThreadPoolExecutor.finalize() line: 1477 >> System$2.invokeFinalize(Object) line: 1267 >> Finalizer.runFinalizer(JavaLangAccess) line: 98 >> Finalizer.access$100(Finalizer, JavaLangAccess) line: 34 >> Finalizer$FinalizerThread.run() line: 210 >> >> That line 694 contains this line: >> (runStateOf(c) == SHUTDOWN && ! workQueue.isEmpty())) // NPE: >> workQueue==null >> >> The "workQueue" is final, and proper checks are in place in the >> constructor won't allow for it to be initialized with null. >> So I believe this is merely the "finalizer" being triggered for an >> instance of ThreadPoolExecutor which was not successfully constructed; >> indeed if I set a breakpoint on the "throw new >> IllegalArgumentException()" line of the constructor, this trips on a >> JMS/HornetQ related stack: >> >> Thread [ServerService Thread Pool -- 64] (Suspended (breakpoint at >> line 1307 in ThreadPoolExecutor)) >> owns: PostOfficeImpl (id=270) >> owns: HornetQServerImpl (id=271) >> owns: JMSServerManagerImpl (id=272) >> owns: JMSService (id=273) >> ThreadPoolExecutor.(int, int, long, TimeUnit, >> BlockingQueue, ThreadFactory, RejectedExecutionHandler) >> line: 1307 >> ThreadPoolExecutor.(int, int, long, TimeUnit, >> BlockingQueue) line: 1195 >> Executors.newFixedThreadPool(int) line: 89 >> UUIDGenerator.getHardwareAddress() line: 151 >> UUIDGenerator.getAddressBytes() line: 263 >> UUIDGenerator.generateStringUUID() line: 206 >> PostOfficeImpl.addBinding(Binding) line: 481 >> HornetQServerImpl.loadJournals() line: 1766 >> HornetQServerImpl.initialisePart2() line: 1593 >> HornetQServerImpl.access$1400(HornetQServerImpl) line: 178 >> HornetQServerImpl$SharedStoreLiveActivation.run() line: 2314 >> HornetQServerImpl.start() line: 435 >> JMSServerManagerImpl.start() line: 490 >> JMSService.doStart(StartContext) line: 155 >> JMSService.access$000(JMSService, StartContext) line: 60 >> JMSService$1.run() line: 94 >> Executors$RunnableAdapter.call() line: 511 >> FutureTask.run() line: 266 >> ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142 >> ThreadPoolExecutor$Worker.run() line: 617 >> JBossThread(Thread).run() line: 745 >> JBossThread.run() line: 122 >> >> This doesn't seem to be a real problem for the finalizer thread as it >> ignores any RuntimeException, and also not a problem for the Executor >> so I guess the puzzle is far less exciting than the subject of this >> email might have made you believe :-) >> But still it would be nice to avoid constructing an illegal Executor, >> and I have no idea if this could be a real problem for those UUID >> Generator services which I see in the stacktrace. >> >> In my integration test I was updating versions of libraries and >> application server to EAP 6.4.0.Alpha, but still using an old >> "standalone.xml" file. I guess the outdated configuration file might >> have fooled some validation. >> >> Thanks, >> Sanne >> _______________________________________________ >> 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 > From tomaz.cerar at gmail.com Wed Jan 28 10:26:10 2015 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 28 Jan 2015 16:26:10 +0100 Subject: [wildfly-dev] IP6 and Any known incompatibilities between these versions? In-Reply-To: <54C8DFF3.9050903@redhat.com> References: <54C8DFF3.9050903@redhat.com> Message-ID: 1) no, latest 8.x jars will handle all previous versions just fine 2) not really just one thing that could cause this, but we did fix few remoting & xnio things in 8.1 on general principal we test all code under ipv6 which is used also by our PR CI jobs. also i would recommend you to go with 8.2.0.Final artifacts On Wed, Jan 28, 2015 at 2:11 PM, Rob Stryker wrote: > Hi all: > > JBT is considering updating the following client jar versions for > communication with all wildfly streams 8.x over management api: > > marshalling from 1.4.3 to 1.4.9 > remoting from 4.0.0 to 4.0.9 > xnio from 3.2.0 to 3.3.0 > protocol from 8.0.0 to 8.2.0.CR1 > controller-client from 8.0.0 to 8.2.0.CR1 > > The cause for this is that when using the current jars, executing > management tasks with ip6 hosts fails against all wf8.x servers. So > far, updating the jars has passed our smoke tests. > > Two questions: > > 1) Are there any known incompatibilities for those new jar versions with > any wf8.0 or higher? ie, should this new set of jars be able to > communicate flawlessly with wf8.0 through 8.2? > > 2) This one's more of a curiousity, but does anyone know what caused the > 8.0 jars to fail against all servers for management over ip6? I've > combed through jira and git logs a bit but nothing really jumped out at me. > > Answers to these two questions would increase our confidence in bumping > the jars more than simple smoke tests. > > - Rob Stryker > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150128/b52fae0b/attachment-0001.html From rstryker at redhat.com Wed Jan 28 10:47:57 2015 From: rstryker at redhat.com (Rob Stryker) Date: Wed, 28 Jan 2015 23:47:57 +0800 Subject: [wildfly-dev] IP6 and Any known incompatibilities between these versions? In-Reply-To: References: <54C8DFF3.9050903@redhat.com> Message-ID: <54C904AD.8020902@redhat.com> On 01/28/2015 11:26 PM, Toma? Cerar wrote: > 1) no, latest 8.x jars will handle all previous versions just fine > 2) not really just one thing that could cause this, but we did fix few > remoting & xnio things in 8.1 > > on general principal we test all code under ipv6 which is used also by > our PR CI jobs. > > also i would recommend you to go with 8.2.0.Final artifacts > Will do, thanks! > On Wed, Jan 28, 2015 at 2:11 PM, Rob Stryker > wrote: > > Hi all: > > JBT is considering updating the following client jar versions for > communication with all wildfly streams 8.x over management api: > > marshalling from 1.4.3 to 1.4.9 > remoting from 4.0.0 to 4.0.9 > xnio from 3.2.0 to 3.3.0 > protocol from 8.0.0 to 8.2.0.CR1 > controller-client from 8.0.0 to 8.2.0.CR1 > > The cause for this is that when using the current jars, executing > management tasks with ip6 hosts fails against all wf8.x servers. So > far, updating the jars has passed our smoke tests. > > Two questions: > > 1) Are there any known incompatibilities for those new jar > versions with > any wf8.0 or higher? ie, should this new set of jars be able to > communicate flawlessly with wf8.0 through 8.2? > > 2) This one's more of a curiousity, but does anyone know what > caused the > 8.0 jars to fail against all servers for management over ip6? I've > combed through jira and git logs a bit but nothing really jumped > out at me. > > Answers to these two questions would increase our confidence in > bumping > the jars more than simple smoke tests. > > - Rob Stryker > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150128/3ef3cd08/attachment.html From eduardo.santanadasilva at gmail.com Wed Jan 28 10:55:43 2015 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Wed, 28 Jan 2015 13:55:43 -0200 Subject: [wildfly-dev] NPE in finalizer of ThreadPoolExecutor In-Reply-To: References: Message-ID: The outdated configuration files can cause problems during distributions, depending upon what you use. I had similar problems too. Try to merge your changes in the configuration file of the current version that you are using if the problem persists I can try to reproduce it using a similar environment. Give it a try and let me know. Thanks Eduardo Sant'Ana da Silva 2015-01-28 13:21 GMT-02:00 Sanne Grinovero : > On 26 January 2015 at 10:15, Eduardo Sant?Ana da Silva > wrote: > > Hello, > > > > Could you provide more information? > > > > > > What is your OS, JVM, and WFLY versions? > > OS -> Linux (custom build, pure 64 bit) > JVM -> OpenJDK 64-Bit 1.7.0_65 > WFLY -> It's actually the preview of EAP 6.4 - as I say below ;-) - > 6.4.0.Alpha > > I suspect the issue is caused by using an outdated configuration file, > this is the one I was using: > > https://github.com/hibernate/hibernate-search/blob/4.4/integrationtest/as/src/as7config/standalone/configuration/standalone-securedjms.xml > > I guess one isn't supposed to use an outdated configuration file? I > don't remember when I forked this configuration file, but it was > probably before EAP 6.2, to make some changes necessary to the > integration tests we run. > > The Arquillian based tests in that same module should be able to > reproduce the issue, although you'd need to make some changes to > upgrade dependencies to EAP 6.4 as that branch is using EAP 6.3. > Unfortunately EAP 6.4 is not in Maven yet so I can't commit the > version changes... but I suspect you'd have the same problem by using > this old configuration file in latest WildFly? > > Thanks, > Sanne > > > > > Which configuration file are you using to startup the server? > > > > Is there any sample app to reproduce your test? > > > > > > Tnanks > > Eduardo Sant'Ana da Silva > > > > > > 2015-01-25 20:18 GMT-02:00 Sanne Grinovero : > >> > >> Hi all, > >> I was investigating this issue which I believed initially to be a JDK > >> bug, but it turns out it's caused by WildFly and I'm not really sure > >> what problems it could cause. > >> > >> The symptom is a NullPointerException being thrown in the "Finalizer" > >> Daemon System Thread, while attempting to shut down a > >> ThreadPoolExecutor: > >> > >> Daemon System Thread [Finalizer] (Suspended (exception > >> NullPointerException)) > >> ThreadPoolExecutor.tryTerminate() line: 694 [local variables > unavailable] > >> ThreadPoolExecutor.shutdown() line: 1394 > >> ThreadPoolExecutor.finalize() line: 1477 > >> System$2.invokeFinalize(Object) line: 1267 > >> Finalizer.runFinalizer(JavaLangAccess) line: 98 > >> Finalizer.access$100(Finalizer, JavaLangAccess) line: 34 > >> Finalizer$FinalizerThread.run() line: 210 > >> > >> That line 694 contains this line: > >> (runStateOf(c) == SHUTDOWN && ! workQueue.isEmpty())) // NPE: > >> workQueue==null > >> > >> The "workQueue" is final, and proper checks are in place in the > >> constructor won't allow for it to be initialized with null. > >> So I believe this is merely the "finalizer" being triggered for an > >> instance of ThreadPoolExecutor which was not successfully constructed; > >> indeed if I set a breakpoint on the "throw new > >> IllegalArgumentException()" line of the constructor, this trips on a > >> JMS/HornetQ related stack: > >> > >> Thread [ServerService Thread Pool -- 64] (Suspended (breakpoint at > >> line 1307 in ThreadPoolExecutor)) > >> owns: PostOfficeImpl (id=270) > >> owns: HornetQServerImpl (id=271) > >> owns: JMSServerManagerImpl (id=272) > >> owns: JMSService (id=273) > >> ThreadPoolExecutor.(int, int, long, TimeUnit, > >> BlockingQueue, ThreadFactory, RejectedExecutionHandler) > >> line: 1307 > >> ThreadPoolExecutor.(int, int, long, TimeUnit, > >> BlockingQueue) line: 1195 > >> Executors.newFixedThreadPool(int) line: 89 > >> UUIDGenerator.getHardwareAddress() line: 151 > >> UUIDGenerator.getAddressBytes() line: 263 > >> UUIDGenerator.generateStringUUID() line: 206 > >> PostOfficeImpl.addBinding(Binding) line: 481 > >> HornetQServerImpl.loadJournals() line: 1766 > >> HornetQServerImpl.initialisePart2() line: 1593 > >> HornetQServerImpl.access$1400(HornetQServerImpl) line: 178 > >> HornetQServerImpl$SharedStoreLiveActivation.run() line: 2314 > >> HornetQServerImpl.start() line: 435 > >> JMSServerManagerImpl.start() line: 490 > >> JMSService.doStart(StartContext) line: 155 > >> JMSService.access$000(JMSService, StartContext) line: 60 > >> JMSService$1.run() line: 94 > >> Executors$RunnableAdapter.call() line: 511 > >> FutureTask.run() line: 266 > >> ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1142 > >> ThreadPoolExecutor$Worker.run() line: 617 > >> JBossThread(Thread).run() line: 745 > >> JBossThread.run() line: 122 > >> > >> This doesn't seem to be a real problem for the finalizer thread as it > >> ignores any RuntimeException, and also not a problem for the Executor > >> so I guess the puzzle is far less exciting than the subject of this > >> email might have made you believe :-) > >> But still it would be nice to avoid constructing an illegal Executor, > >> and I have no idea if this could be a real problem for those UUID > >> Generator services which I see in the stacktrace. > >> > >> In my integration test I was updating versions of libraries and > >> application server to EAP 6.4.0.Alpha, but still using an old > >> "standalone.xml" file. I guess the outdated configuration file might > >> have fooled some validation. > >> > >> Thanks, > >> Sanne > >> _______________________________________________ > >> 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 > > > -- __________________________ 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/20150128/ce69d7d1/attachment.html From darran.lofthouse at jboss.com Sat Jan 31 05:52:27 2015 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Sat, 31 Jan 2015 05:52:27 -0500 (EST) Subject: [wildfly-dev] Architecture Guides - Which tool(s) should I use? In-Reply-To: <716722413.4257805.1422701154878.JavaMail.zimbra@redhat.com> Message-ID: <282377083.4257913.1422701547834.JavaMail.zimbra@redhat.com> Hi all, Just looking for some feedback for tools currently being used to achieve something similar to the following. I am looking to produce a couple of different architecture guides for the changes being made for security, in general for both guides I am looking to add a high level digram that shows the security components and the components within the digram should be clickable to link to the appropriate section in the document. One thing I would like in the representations of the components is that they support nesting so for example a box called 'authentication mechanisms' could contain both 'sasl mechanisms' and 'http mechanisms'. Ideally this should be in a git repo so we can accept contributions easily using tools readily available. Regards, Darran Lofthouse. From ozizka at redhat.com Sat Jan 31 07:34:07 2015 From: ozizka at redhat.com (Ondrej Zizka) Date: Sat, 31 Jan 2015 13:34:07 +0100 Subject: [wildfly-dev] WildFly SelfMonitor submodule Message-ID: <54CCCBBF.7090806@redhat.com> Hi all, a module for self-monitoring of WildFly was the goal of the diploma thesis by Vojtech Schlemmer. I know that in the meantime, Heiko created a submodule for the same purpose. Still, it could be worth looking at Vojtech's result: https://is.muni.cz/th/325163/fi_m/?furl=%2Fth%2F325163%2Ffi_m%2F;so=nx;lang=en For docs see the text of the thesis (in English), for working configured server download the Appendix. It is configurable through CLI (what to monitor, interval of each monitored metric, aggregation). One distinctive feature is storing into a database using WildFly's datasource (IIRC the other doesn't have it). Copy on GitHub: https://github.com/OndraZizka/wildfly-selfmonitor It's a rough prototype, so the implementation of some features is really basic and, so to say, not optimal. Enjoy :) From mazz at redhat.com Sat Jan 31 09:16:19 2015 From: mazz at redhat.com (John Mazzitelli) Date: Sat, 31 Jan 2015 09:16:19 -0500 (EST) Subject: [wildfly-dev] WildFly SelfMonitor submodule In-Reply-To: <54CCCBBF.7090806@redhat.com> References: <54CCCBBF.7090806@redhat.com> Message-ID: <1056675231.4456692.1422713779877.JavaMail.zimbra@redhat.com> I believe one of the goals of Heiko's wildfly-monitor subsystem was that it would be able to be deployed in Wildfly-Core (thus being able to monitor any wildfly instance) - hence, not allowed to have a dependency on Wildfly's database/datasource (IIRC, wildfly-core doesn't have any DB available out of box) ----- Original Message ----- > Hi all, > > a module for self-monitoring of WildFly was the goal of the diploma > thesis by Vojtech Schlemmer. > > I know that in the meantime, Heiko created a submodule for the same purpose. > Still, it could be worth looking at Vojtech's result: > https://is.muni.cz/th/325163/fi_m/?furl=%2Fth%2F325163%2Ffi_m%2F;so=nx;lang=en > For docs see the text of the thesis (in English), for working configured > server download the Appendix. > It is configurable through CLI (what to monitor, interval of each > monitored metric, aggregation). > One distinctive feature is storing into a database using WildFly's > datasource (IIRC the other doesn't have it). > > Copy on GitHub: https://github.com/OndraZizka/wildfly-selfmonitor > > It's a rough prototype, so the implementation of some features is really > basic and, so to say, not optimal. > > Enjoy :) > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >