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
Referencing BouncyCastle
by Rebecca Searls
Need wildFly to use bouncycastle for cxf tests.
Add bouncycastle ref in standalone.xml as follows:
<subsystem xmlns="urn:jboss:domain:ee:2.0">
<global-modules>
<module name="org.bouncycastle" slot="main"/>
</global-modules>
:
But it does not appear to be found and getting stacktrace.
Any suggestions?
13:45:10,529 ERROR [stderr] (default task-3) java.lang.Exception: Please check that the Bouncy Castle provider is installed.
13:45:10,529 ERROR [stderr] (default task-3) at org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.invoke(SignEncryptHelper.java:94)
13:45:10,529 ERROR [stderr] (default task-3) at org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.testSignEncryptUsingConfigProperties(SignEncryptHelper.java:72)
13:45:10,529 ERROR [stderr] (default task-3) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
13:45:10,529 ERROR [stderr] (default task-3) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
13:45:10,529 ERROR [stderr] (default task-3) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
13:45:10,529 ERROR [stderr] (default task-3) at java.lang.reflect.Method.invoke(Method.java:606)
13:45:10,530 ERROR [stderr] (default task-3) at org.jboss.wsf.test.TestServlet.invokeMethod(TestServlet.java:152)
13:45:10,530 ERROR [stderr] (default task-3) at org.jboss.wsf.test.TestServlet.doGet(TestServlet.java:89)
13:45:10,530 ERROR [stderr] (default task-3) at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
13:45:10,530 ERROR [stderr] (default task-3) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
13:45:10,530 ERROR [stderr] (default task-3) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87)
13:45:10,530 ERROR [stderr] (default task-3) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
13:45:10,530 ERROR [stderr] (default task-3) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
13:45:10,531 ERROR [stderr] (default task-3) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:70)
13:45:10,531 ERROR [stderr] (default task-3) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
13:45:10,531 ERROR [stderr] (default task-3) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
13:45:10,531 ERROR [stderr] (default task-3) at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
13:45:10,531 ERROR [stderr] (default task-3) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
13:45:10,531 ERROR [stderr] (default task-3) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
13:45:10,531 ERROR [stderr] (default task-3) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:67)
13:45:10,532 ERROR [stderr] (default task-3) at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70)
13:45:10,532 ERROR [stderr] (default task-3) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
13:45:10,532 ERROR [stderr] (default task-3) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
13:45:10,532 ERROR [stderr] (default task-3) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
13:45:10,532 ERROR [stderr] (default task-3) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
13:45:10,532 ERROR [stderr] (default task-3) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
13:45:10,532 ERROR [stderr] (default task-3) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
13:45:10,533 ERROR [stderr] (default task-3) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
13:45:10,533 ERROR [stderr] (default task-3) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
13:45:10,533 ERROR [stderr] (default task-3) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:164)
13:45:10,533 ERROR [stderr] (default task-3) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:654)
13:45:10,533 ERROR [stderr] (default task-3) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
13:45:10,533 ERROR [stderr] (default task-3) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
13:45:10,533 ERROR [stderr] (default task-3) at java.lang.Thread.run(Thread.java:724)
13:45:10,534 ERROR [stderr] (default task-3) Caused by: javax.xml.ws.soap.SOAPFaultException: Cannot encrypt data
13:45:10,534 ERROR [stderr] (default task-3) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:157)
13:45:10,534 ERROR [stderr] (default task-3) at com.sun.proxy.$Proxy280.sayHello(Unknown Source)
13:45:10,534 ERROR [stderr] (default task-3) at org.jboss.test.ws.jaxws.samples.wsse.policy.basic.SignEncryptHelper.invoke(SignEncryptHelper.java:90)
13:45:10,534 ERROR [stderr] (default task-3) ... 33 more
13:45:10,534 ERROR [stderr] (default task-3) Caused by: org.apache.cxf.ws.policy.PolicyException: Cannot encrypt data
13:45:10,535 ERROR [stderr] (default task-3) at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:294)
13:45:10,535 ERROR [stderr] (default task-3) at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doEncryption(AsymmetricBindingHandler.java:461)
13:45:10,535 ERROR [stderr] (default task-3) at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:190)
13:45:10,535 ERROR [stderr] (default task-3) at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.handleBinding(AsymmetricBindingHandler.java:98)
13:45:10,535 ERROR [stderr] (default task-3) at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:176)
13:45:10,535 ERROR [stderr] (default task-3) at org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$PolicyBasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInterceptor.java:90)
13:45:10,535 ERROR [stderr] (default task-3) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272)
13:45:10,535 ERROR [stderr] (default task-3) at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:565)
13:45:10,536 ERROR [stderr] (default task-3) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474)
13:45:10,536 ERROR [stderr] (default task-3) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377)
13:45:10,536 ERROR [stderr] (default task-3) at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330)
13:45:10,536 ERROR [stderr] (default task-3) at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
13:45:10,536 ERROR [stderr] (default task-3) at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
13:45:10,536 ERROR [stderr] (default task-3) ... 35 more
13:45:12,533 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017535: Unregister web context: /jaxws-samples-wsse-policy-sign-encrypt-gcm
11 years, 11 months
JDK 8 Build 123 & JDK 7 Update 60 build 02 are available on java.net
by Rory O'Donnell Oracle, Dublin Ireland
Hi Guys,
Haven't heard from you in sometime, hope all is progressing well. Please
let me know if you are seeing any issues.
JDK 8 Build b123 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
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, 12 months
Misc questions about WF8
by Arun Gupta
- There are a bunch of ports listed in different
<socket-binding-group>s in domain.xml such as for jacorb, groups-tcp,
and messaging. I thought that only two ports are exposed by WildFly.
What purpose do these ports serve ? What about 8443 ?
- What is new in jboss-cli.sh in WildFly from AS 7 ?
- Where can I find the complete feature set for everything new in WF8 ?
Thanks
Arun
--
http://blog.arungupta.me
http://twitter.com/arungupta
11 years, 12 months
Remoting port
by Filippe Costa Spolti
Hello guys.
Let me ask something.
In the WildFly announcements says that the remoting port was deprecated,
but in WFLY CR1 the port still present.
Here: http://wildfly.org/news/2013/12/21/WildFly8-CR1-Released/
But when i start the standalone mode the port 9990 appears:
[root@wfly_tests ~]# netstat -anp | grep java
tcp 0 0 127.0.0.1:9999 0.0.0.0:*
LISTEN 3070/java
tcp 0 0 192.168.11.109:8080 0.0.0.0:*
LISTEN 3070/java
tcp 0 0 127.0.0.1:9990 0.0.0.0:*
LISTEN 3070/java
This port will be removed only in the Final version?
--
Regards,
______________________________________
Filippe Costa Spolti
Linux User n°515639 - http://counter.li.org/
filippespolti(a)gmail.com
"Be yourself"
<http://www.linkedin.com/pub/filippe-costa-spolti/67/985/575>
12 years
WildFly 8 - list of missing features?
by Jaromir Hamala
Hi guys,
I wonder if there is a list of features implemented in JBoss AS 7, but
missing from the WildFly 8? It would make migration assessments way easier.
I stumbled upon the issue with SAML (
https://issues.jboss.org/browse/PLINK2-119) and I wonder what are the other
features missing in the current WildFly.
Cheers,
Jaromir
--
“Perfection is achieved, not when there is nothing more to add, but when
there is nothing left to take away.”
Antoine de Saint Exupéry
12 years
Removing curl support from management HTTP
by Darran Lofthouse
Hello all,
Just starting to plan some upstream changes for WildFly and just wanted
to gauge how much simple http tools like curl are in use?
If we were to completely disable their use would it cause problems?
Note: Where management messages are sent in using code to construct a
HTTP request this will still be possible with minor changes to the
message exchanges.
Regards,
Darran Lofthouse.
12 years
