December 2013 - wildfly-dev - Jboss List Archives

by Alexey Loubyansky

There is this issue to provide CLI preferences https://issues.jboss.org/browse/WFLY-1063. Here I'd like to address mainly this part "prod-db = /subsystem=jadada/database=jadada/ so you could call prod-db:read-resource" I'd like to get some opinion on the way it's gonna be implemented (and what I've done so far on a local branch). So, to address that I introduced variables. A variable starts with a $, e.g. $prod_db. (Using simply prod_db is not a good idea since it might conflict with actual parts of the paths, names, etc) Variables can be introduced with [disconnected /] set prod_db=/subsystem=datasources/data-source=ExampleDS Read with [standalone@localhost:9990 /] echo prod_db /subsystem=datasources/data-source=ExampleDS And unset with [standalone@localhost:9990 /] unset prod_db 'echo' without parameters will list all the variables and their values, 'set prod_db=' will have the same effect as 'unset prod_db', set/echo/unset will work with and w/o '$' prefix, tab-completion works everywhere. The variables may appear in: - operation request addresses, e.g. $prod_db/statistics=jdbc:read-resource; - operation names, e.g. $prod_db:$op(include-runtime=true); - operation parameter names and values, e.g. $prod_db:$op($param=$param_value); - the same for commands. Tab-completion helps complete the names as long as you type in '$' and then the rest of the line after the variable as usual. Variables added during the session are not persisted anywhere. But I've added .jbossclirc file. This file can be located in the current directory, wildfly home bin directory or specified with a system property. The content of the file is usual CLI commands and/or operations. So, the variables could be initialized there. This file, if located, will be executed before the CLI session (interactive or not) starts (but also after the system properties specified with --properties are set). As a side effect, '$' is now a special character and will have to be escaped. Otherwise the CLI might complain about an unresolved variable. So, this could potentially cause problems for existing scripts using $. Note, most of this replacement stuff can already be done with system properties using ${xxx} format (and btw scripts using '$' as in '${xxx}' won't be affected, of course). And for now I've made variable names follow the rules for Java identifiers. Any remarks, objections or suggestions? Thanks, Alexey

11 years, 10 months

4
13
0 / 0

Re: [wildfly-dev] xnio selection err

by Jason Greene

Oops Sent from my iPhone > On Dec 27, 2013, at 9:00 AM, Jason Greene <jgreene(a)redhat.com> wrote: > > Any chance you can get a stack trace out of it? Upping the log level or using a debugger to catch IOException would do the trick. > > The error means the OS is throwing EINVAL. > > Is this a OSX Mavericks? If so can you double check you are running the latest JVM? > > Sent from my iPhone > >> On Dec 27, 2013, at 8:36 AM, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote: >> >> Isn't that the same error that happens only on your mac also in few other cases? >> >> Can you try on any other platform? >> >> Sent from my Phone >> From: Ales Justin >> Sent: ‎27.‎12.‎2013 14:14 >> To: Wildfly Dev mailing list >> Subject: [wildfly-dev] xnio selection err >> >> While using UnderTow's JSR WebSockets, >> implementing simple chat app, between 2 diff browsers (Chrome and Safari), >> I get a flood of these log lines: >> >> 14:09:22,890 WARN [org.xnio.nio.selector] (default I/O-3) XNIO008000: Received an I/O error on selection: java.io.IOException: Invalid argument >> >> Any idea? >> >> -Ales >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev

11 years, 11 months

4
10
0 / 0

13 JASPIC tests failing on WildFly

by arjan tijms

Hi, I had stressed for standardization of the JASPI configuration. The spec > lead wanted to keep it open. This was early days of the JSR. > I seriously doubt you can have auth modules written once and deploy on > any app server. > Actually it doesn't seem to be that bad. Using the programmatic registration method (which is the only standardized method) pretty much every app server installs the SAM just fine (Geronimo is the sole exception). Yes, the first time it's a hassle that you have to code the wrapper AuthConfigProvider, ServerAuthConfig etc types, but once you hide that away inside a utility method it's a one liner to install a SAM from a ServletContextListener. This is exactly what the tests that I committed do: @WebListener public class SamAutoRegistrationListener extends BaseServletContextListener { @Override public void contextInitialized(ServletContextEvent sce) { JaspicUtils.registerSAM(sce.getServletContext(), new TestServerAuthModule()); } } It's perhaps a shame there's no declarative alternative, but this method itself is IMHO not wrong per se. The Servlet spec defines similar APIs for registering Servlets and Filters programmatically. After working with JASPIC rather intensively for well over a year now I can say that it does work in a portable way. The main issue is the multitude of bugs in the various implementations and/or implementations just not doing what's in the spec. For instance, secureResponse should be called AFTER the resource (e.g. a Servlet or JSP page) is invoked, but some implementations erroneously call it before the resource is invoked. This makes it impossible to use this method for a SAM that has to be portable. The spec is clear on this topic, but the app servers just don't always do the right thing. Some aspects of the spec are just ignored by pretty much all servers, like the ability of a SAM to wrap the request and response objects (just like a Servlet Filter can do). For the open source servers it can be seen that this functionality is not even attempted. Ironically, GlassFish does attempt it, but due to a rather complicated bug it eventually fails to deliver the wrapped request to the resource, while it does deliver the wrapped response correctly. So IMHO 90% of the non-portability of a SAM is just due to implementation bugs. Many of them are rather trivial to fix. Hopefully having a series of tests can help remedy this issue ;) Kind regards, Arjan Tijms > That was the goal of the spec but I don't think it really has reached > that potential. > As Stefan said, let us wait for all the JASPI related PRs to be merged > before looking into > the failures. On 12/11/2013 08:12 AM, Arun Gupta wrote: >* I changed the <security-domain> to: *>>* <security-domain name="jaspitest" cache-type="default"> *>* <authentication-jaspi> *>* <login-module-stack name="dummy"> *>* <login-module code="Dummy" flag="optional"/> *>* </login-module-stack> *>* <auth-module *>* code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule" *>* flag="required"/> *>* </authentication-jaspi> *>* </security-domain> *>>* and getting more failures. Will wait for the PR to be merged. *>>* Arun *>>* On Wed, Dec 11, 2013 at 6:07 AM, Stefan Guilhen <sguilhen at redhat.com <https://lists.jboss.org/mailman/listinfo/wildfly-dev>> wrote: *>>* Actually they seem to be registering their own AuthConfigProvider, in *>>* which case the dummy domain setup is fine (configuring our auth-module *>>* impl won't do anything as their provider will register their own test *>>* module), so disregard my previous e-mail. *>>>>* Note that there is a pending pull request *>>* (https://github.com/wildfly/wildfly/pull/5558/ <https://github.com/wildfly/wildfly/pull/5558/>) that seems to fix a few *>>* of the issues seen in the tests. Lets run the tests again once the PR is *>>* merged to and see where we stand. *>>>>* Stefan *>>>>* On 12/11/2013 10:52 AM, Stefan Guilhen wrote: *>>>* If you are using the security domain as mentioned in the commit any *>>>* authentication will fail because there is no "dummy" auth-module. I *>>>* couldn't find the WildFly log but there must be exceptions there *>>>* indicating it was not possible to load the auth-module class. *>>>>>>* Try setting the auth module in the security domain to *>>>>>>* <auth-module *>>>* code="org.wildfly.extension.undertow.security.jaspi.modules.HTTPSchemeServerAuthModule" *>>>* flag="required"/> *>>>>>>* And see how it goes. *>>>>>>* Stefan *>>>>>>* On 12/10/2013 10:16 PM, Arun Gupta wrote: *>>>>* Arjan Tims has added 22 new JASPIC tests to Java EE 7 test suite at: *>>>>>>>>* https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic <https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic> *>>>>>>>>* 13 of them are failing with WildFly as shown at: *>>>>>>>>* https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20Wil... <https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20Wil...> *>>>>>>>>* 21 of these tests are passing on GlassFish as shown at: *>>>>>>>>* https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20Gla... <https://arungupta.ci.cloudbees.com/job/Java%20EE%207%20Samples%20on%20Gla...> *>>>>>>>>* JASPIC support in WildFly is reported "broken" as mentioned at: *>>>>>>>>* https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b4... <https://github.com/arjantijms/jaspic-capabilities-test/commit/7f78a8267b4...> *>>>>>>>>* Adding a new <security-domain> as mentioned in the above commit *>>>>* message only marginally improves the results. *>>>>>>>>* Do you see any basic configuration issue with OOTB WildFly for running *>>>>* these tests ? *>>>>>>>>* Arun *>>>

11 years, 11 months

4
14
0 / 0

New Year's Eve bug broke the build

by ssilvert＠redhat.com

https://github.com/wildfly/wildfly/pull/5653 I'm not sure if this is a bug in the test or a bug in org.jboss.as.ejb3.timerservice.schedule.CalendarBasedTimeout. But I'm pretty sure that the build will be working again in a few hours. Happy New Year!

11 years, 11 months

5
11
0 / 0

WildFly 8.0.0.CR1 Released!

by Jason Greene

Read all about it! http://wildfly.org/news/2013/12/21/WildFly8-CR1-Released/ -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

11 years, 11 months

7
6
0 / 0

admin console question/resources

by Nick Mpallas

Hi guys, according tot he new JMS API 2.0 you can use the @JMSDestinationDefinition to define the queue resources you want to have. The functionality is correct. When I deploy my module I can see it creates the resource as expected. But when I go to the admin console interface, under the queue I don't see this resource. Only the ones defined through the jboss-cli or directly by editing the *.xml configuration file, will be available to be monitored by the console? Shouldn't the console provide insights for the other stuff also? have fun -- \n\m "camel is a horse made up in a laboratory"

11 years, 11 months

3
3
0 / 0

app policy race

by Ales Justin

I often get this error: * https://gist.github.com/alesj/8146623 I guess it's related to https://issues.jboss.org/browse/SECURITY-777 ? Do we have a JIRA for WF as well? -Ales

11 years, 11 months

4
6
0 / 0

Re: [wildfly-dev] xnio selection err

by Tomaž Cerar

Isn't that the same error that happens only on your mac also in few other cases? Can you try on any other platform? Sent from my Phone ------------------------------ From: Ales Justin <ales.justin(a)gmail.com> Sent: ‎27.‎12.‎2013 14:14 To: Wildfly Dev mailing list <wildfly-dev(a)lists.jboss.org> Subject: [wildfly-dev] xnio selection err While using UnderTow's JSR WebSockets, implementing simple chat app, between 2 diff browsers (Chrome and Safari), I get a flood of these log lines: 14:09:22,890 WARN [org.xnio.nio.selector] (default I/O-3) XNIO008000: Received an I/O error on selection: java.io.IOException: Invalid argument Any idea? -Ales

11 years, 12 months

1
0
0 / 0

xnio selection err

by Ales Justin

While using UnderTow's JSR WebSockets, implementing simple chat app, between 2 diff browsers (Chrome and Safari), I get a flood of these log lines: 14:09:22,890 WARN [org.xnio.nio.selector] (default I/O-3) XNIO008000: Received an I/O error on selection: java.io.IOException: Invalid argument Any idea? -Ales

11 years, 12 months

1
0
0 / 0

Re: [wildfly-dev] JDK 8 Build 121 & JDK 7 Update 60 build 02 are available on java.net

by Rory O'Donnell Oracle, Dublin Ireland

cc'ing wildfly-dev(a)lists.jboss.org Rgds,Rory On 27/12/2013 13:00, Rory O'Donnell Oracle, Dublin Ireland wrote: > Hi Guys, > > Hope you enjoyed the holidays, all the best for 2014. > > JDK 8 Build b121 Early Access Build is now available for download > <http://jdk8.java.net/download.html> & test. > JDK 7u60 b02 Early Access Build is also available for download > <https://jdk7.java.net/download.html>& test. > > We are now very late in the release cycle of JDK 8 , issues found late > may > be postponed to JDK 9 time frame. Please log all show stopper issues as > soon as possible. > > Thanks for your support, Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

11 years, 12 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

wildfly-dev December 2013