Hello Everyone, I am happy to announce the availability of Alpha3, which is available for download in the usual location: wildfly.org/download Some key updates in this release are: • EJB invocations now use HTTP upgrade over port 8080 • This is a major step towards the port reduction initiative we have for WildFly 8 • WildFly can now be ran as a Windows service • Mod_cluster functionality restored • Bean Validation 1.1 now supported with JAX-RS and CDI • Undertow subsystem and integration improvements • Bytecode enhanced entities now supported in JPA • User creation script also supports groups • Initial support for a syslog logging appender For complete details on what is in Alpha3, see the release notes here: https://community.jboss.org/wiki/800Alpha3ReleaseNotes If anyone notices an area I missed, or wishes to add additional notes, feel free to update the wiki entry. Thanks! -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

• EJB invocations now use HTTP upgrade over port 8080

From: "Jason Greene" <jason.greene(a)redhat.com&gt; To: wildfly-dev(a)lists.jboss.org Sent: Wednesday, July 17, 2013 11:06:26 PM Subject: [wildfly-dev] 8.0.0.Alpha3 Released! Hello Everyone, I am happy to announce the availability of Alpha3, which is available for download in the usual location: wildfly.org/download Some key updates in this release are: • EJB invocations now use HTTP upgrade over port 8080 • This is a major step towards the port reduction initiative we have for WildFly 8 • WildFly can now be ran as a Windows service • Mod_cluster functionality restored • Bean Validation 1.1 now supported with JAX-RS and CDI • Undertow subsystem and integration improvements • Bytecode enhanced entities now supported in JPA • User creation script also supports groups • Initial support for a syslog logging appender For complete details on what is in Alpha3, see the release notes here: https://community.jboss.org/wiki/800Alpha3ReleaseNotes If anyone notices an area I missed, or wishes to add additional notes, feel free to update the wiki entry. Thanks! -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

From: "Jason Greene" <jason.greene(a)redhat.com&gt; To: "Bill Burke" <bburke(a)redhat.com&gt; Cc: wildfly-dev(a)lists.jboss.org Sent: Thursday, July 18, 2013 11:40:47 AM Subject: [wildfly-dev] HTTP Upgrade Options (Re: 8.0.0.Alpha3 Released!) On Jul 18, 2013, at 7:51 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: > > > On 7/18/2013 1:06 AM, Jason Greene wrote: >> • EJB invocations now use HTTP upgrade over port 8080 > > Very cool! Every remoting protocol headed this way?! That's > awesome! Yes thats the plan. Although maybe you and others could share your opinion on something. We have been looking as a goal to create two profiles: 1. Two ports - 8080 (application = servlet, ejb, remote jndi, jms) 9990 (management = native management, HTTP/JSON managmeent, web console, JMX) 2. One port - 8080 (all of the above) AJP & IIOP can't be multiplexed and would be disabled by default. Using SSL would either add or replace the above ports. So the big question is which configuration is the better default. Administrators like the 2 port because its easy to separate access. For example, today when you start wildfly with -b 0.0.0.0 or whatever, it only affects the application ports and not the management port. It's also easy to firewall. One port is in big demand for massive hosting environments like openshift. Going to one port would probably mean we would need to add some ip pattern restriction features to standalone.xml, but I'm not sure this is a good substitute because administrators won't be familiar with it, but they already know how to use iptables and -b. Any thoughts?

-- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

From: "Jason Greene" <jason.greene(a)redhat.com&gt; To: "Andrig Miller" <anmiller(a)redhat.com&gt; Cc: wildfly-dev(a)lists.jboss.org, "Bill Burke" <bburke(a)redhat.com&gt; Sent: Thursday, July 18, 2013 12:54:08 PM Subject: Re: [wildfly-dev] HTTP Upgrade Options (Re: 8.0.0.Alpha3 Released!) On Jul 18, 2013, at 12:51 PM, Andrig Miller <anmiller(a)redhat.com&gt; wrote: > > > ----- Original Message ----- >> From: "Jason Greene" <jason.greene(a)redhat.com&gt; >> To: "Bill Burke" <bburke(a)redhat.com&gt; >> Cc: wildfly-dev(a)lists.jboss.org >> Sent: Thursday, July 18, 2013 11:40:47 AM >> Subject: [wildfly-dev] HTTP Upgrade Options (Re: 8.0.0.Alpha3 >> Released!) >> >> >> On Jul 18, 2013, at 7:51 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: >> >>> >>> >>> On 7/18/2013 1:06 AM, Jason Greene wrote: >>>> • EJB invocations now use HTTP upgrade over port 8080 >>> >>> Very cool! Every remoting protocol headed this way?! That's >>> awesome! >> >> >> Yes thats the plan. Although maybe you and others could share your >> opinion on something. We have been looking as a goal to create two >> profiles: >> >> 1. Two ports - 8080 (application = servlet, ejb, remote jndi, jms) >> 9990 (management = native management, HTTP/JSON >> managmeent, web console, JMX) >> 2. One port - 8080 (all of the above) >> >> AJP & IIOP can't be multiplexed and would be disabled by default. >> Using SSL would either add or replace the above ports. >> >> So the big question is which configuration is the better default. >> Administrators like the 2 port because its easy to separate >> access. >> For example, today when you start wildfly with -b 0.0.0.0 or >> whatever, it only affects the application ports and not the >> management port. It's also easy to firewall. One port is in big >> demand for massive hosting environments like openshift. Going to >> one >> port would probably mean we would need to add some ip pattern >> restriction features to standalone.xml, but I'm not sure this is a >> good substitute because administrators won't be familiar with it, >> but they already know how to use iptables and -b. >> >> Any thoughts? >> > > One port is interesting in that it becomes like Weblogic. The > management aspect would still require separate authentication > anyway (management user vs. application user), so I'm not that > sure that the management port being separate is really a big win > for administrators. Yeah, thats a good point that is not that weak as a default (and we bind to localhost by default anyway). However, I could see people still wanting management locked to a separate interface with different firewall policies, since you don't have to worry about a bad password being all that stands in the way from someone breaking into your infrastructure. > > What could be interesting is see if we can run a community poll, > through the Andiamo community site. If we promote to poll through > all our blogs, maybe we can get some good community feedback? Thats a good idea. I would love to get feedback on this.

> Andy > >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)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

> > So, how about a poll, that looks like the following: > > Would you prefer two ports - 8080 (application = servlet, ejb, remote jndi, > jms) and 9990 (management = native management, HTTP/JSON managmeent, web > console, JMX) or alternatively: > > One port - 8080 (for everything including management)? > > Maybe a simply checkbox, and perhaps the explanation of TLS/SSL too? > Presumably the poll would indicate that this is choosing the default, right? Ie, ultimately both approaches will be possible?

On Jul 18, 2013, at 12:51 PM, Andrig Miller <anmiller(a)redhat.com&gt; wrote: > > > ----- Original Message ----- >> From: "Jason Greene" <jason.greene(a)redhat.com&gt; >> To: "Bill Burke" <bburke(a)redhat.com&gt; >> Cc: wildfly-dev(a)lists.jboss.org >> Sent: Thursday, July 18, 2013 11:40:47 AM >> Subject: [wildfly-dev] HTTP Upgrade Options (Re: 8.0.0.Alpha3 Released!) >> >> >> On Jul 18, 2013, at 7:51 AM, Bill Burke <bburke(a)redhat.com&gt; wrote: >> >>> >>> >>> On 7/18/2013 1:06 AM, Jason Greene wrote: >>>> • EJB invocations now use HTTP upgrade over port 8080 >>> >>> Very cool! Every remoting protocol headed this way?! That's >>> awesome! >> >> >> Yes thats the plan. Although maybe you and others could share your >> opinion on something. We have been looking as a goal to create two >> profiles: >> >> 1. Two ports - 8080 (application = servlet, ejb, remote jndi, jms) >> 9990 (management = native management, HTTP/JSON >> managmeent, web console, JMX) >> 2. One port - 8080 (all of the above) >> >> AJP & IIOP can't be multiplexed and would be disabled by default. >> Using SSL would either add or replace the above ports. >> >> So the big question is which configuration is the better default. >> Administrators like the 2 port because its easy to separate access. >> For example, today when you start wildfly with -b 0.0.0.0 or >> whatever, it only affects the application ports and not the >> management port. It's also easy to firewall. One port is in big >> demand for massive hosting environments like openshift. Going to one >> port would probably mean we would need to add some ip pattern >> restriction features to standalone.xml, but I'm not sure this is a >> good substitute because administrators won't be familiar with it, >> but they already know how to use iptables and -b. >> >> Any thoughts? >> > > One port is interesting in that it becomes like Weblogic. The management aspect would still require separate authentication anyway (management user vs. application user), so I'm not that sure that the management port being separate is really a big win for administrators. Yeah, thats a good point that is not that weak as a default (and we bind to localhost by default anyway). However, I could see people still wanting management locked to a separate interface with different firewall policies, since you don't have to worry about a bad password being all that stands in the way from someone breaking into your infrastructure. > > What could be interesting is see if we can run a community poll, through the Andiamo community site. If we promote to poll through all our blogs, maybe we can get some good community feedback? Thats a good idea. I would love to get feedback on this.

On 7/18/2013 4:04 PM, Andrig Miller wrote: > One port - 8080 (for everything including management)? > > Maybe a simply checkbox, and perhaps the explanation of TLS/SSL too? I didn't understand Jason's SSL comments. By default you'd need both an ssl port and non-ssl port, wouldn't you?

Hello Everyone, I am happy to announce the availability of Alpha3, which is available for download in the usual location: wildfly.org/download Some key updates in this release are: • EJB invocations now use HTTP upgrade over port 8080 • This is a major step towards the port reduction initiative we have for WildFly 8 • WildFly can now be ran as a Windows service • Mod_cluster functionality restored • Bean Validation 1.1 now supported with JAX-RS and CDI • Undertow subsystem and integration improvements • Bytecode enhanced entities now supported in JPA • User creation script also supports groups • Initial support for a syslog logging appender For complete details on what is in Alpha3, see the release notes here: https://community.jboss.org/wiki/800Alpha3ReleaseNotes If anyone notices an area I missed, or wishes to add additional notes, feel free to update the wiki entry. Thanks! -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev