October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1730) Singleton service is not correctly being set in WILDFLY

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1730?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1730: ------------------------------------------------- Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1367793|https://bugzilla.redhat.com/show_bug.cgi?id=1367793] from ON_QA to VERIFIED > Singleton service is not correctly being set in WILDFLY > ------------------------------------------------------- > > Key: WFCORE-1730 > URL: https://issues.jboss.org/browse/WFCORE-1730 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 3.0.0.Alpha5 > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > WILDFLY doesn't call ServiceLoader (META-INF/services/org.jboss.msc.service.ServiceActivator) when it is deployed in EAR/lib. The SingletonService (not a singleton EJB) is activated in the ServiceLoader so the SingletonService hasn't been activated from the first. It works as expected when deployed as an EJB (not in EAR/lib). > When the ServiceLoader is called, a message of "HATimerService will be installed!" is logged and the SingletonService will be activated. > $ fgrep -e HATimerService -e '[org.jboss.as.clustering.singleton]' domain/servers/server-one/log/server.log > 12:14:52,373 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator] (MSC service thread 1-7) HATimerService will be installed! > 12:14:56,251 INFO [org.jboss.as.clustering.singleton] (ServerService Thread Pool -- 54) JBAS010342: master:server-one/singleton elected as the singleton provider of the jboss.quickstart.ha.singleton.timer service > 12:14:56,251 INFO [org.jboss.as.clustering.singleton] (ServerService Thread Pool -- 54) JBAS010340: This node will now operate as the singleton provider of the jboss.quickstart.ha.singleton.timer service > 12:14:56,268 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerService] (MSC service thread 1-8) Start HASingleton timer service 'org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATim > erService' > 12:14:56,873 INFO [org.jboss.as.clustering.singleton] (notification-thread-0) JBAS010342: master:server-one/singleton elected as the singleton provider of the jboss.quickstart.ha.singleton.timer service -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ] Shigeru Chiba commented on JASSIST-261: --------------------------------------- I've released 3.22.0-CR1, which can run on the Java 9 VM. https://github.com/jboss-javassist/javassist/releases/tag/rel_3_22_0_cr1 > Issue with javassist on jdk 9b112 > --------------------------------- > > Key: JASSIST-261 > URL: https://issues.jboss.org/browse/JASSIST-261 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.20.0-GA > Environment: Javassist with jdk 9b112 > Reporter: Hoang Chuong Tran > Assignee: Shigeru Chiba > > I am migrating a project to java 9, which also uses javassist to generate runtime code. > One test of mine fails on jdk 9b112 while it passes on jdk 8u77. > {noformat} > import static javassist.CtClass.voidType; > import java.lang.reflect.Method; > import java.lang.reflect.Modifier; > import java.util.HashMap; > import java.util.Map; > import org.junit.Test; > import javassist.ClassClassPath; > import javassist.ClassPool; > import javassist.CtClass; > import javassist.CtField; > import javassist.CtMethod; > import javassist.CtNewMethod; > public class MyTests { > public static class MyObject { > protected Object field; > Object getField() {return field;} > public void setField(Object field) {} > } > @Test > public void test() throws InstantiationException, IllegalAccessException { > Class<? extends MyObject> clazz = compile(MyObject.class); > clazz.newInstance().setField(null); > } > /** Compile a transfer class */ > public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) { > // Determine class setters > Map<String, Method> setters = extractSetters(targetClass); > ClassPool classPool = ClassPool.getDefault(); > classPool.insertClassPath(new ClassClassPath(targetClass)); > try { > // Compile a new transfer class on the fly > CtClass baseClass = classPool.get(MyObject.class.getName()); > CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass); > for(Method originalSetter : setters.values()) { > // Create a field to hold the attribute > Class<?> fieldClass = originalSetter.getParameterTypes()[0]; > CtClass fieldType = classPool.get(fieldClass.getName()); > String fieldName = originalSetter.getName().substring(3); > CtField field = new CtField(fieldType, fieldName, proxyClass); > proxyClass.addField(field); > // Create a setter method to set that field > CtClass[] parameters = new CtClass[] { fieldType }; > String setterBody = "{ System.out.println(\"Hello World\"); }"; > CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass); > proxyClass.addMethod(setter); > } > Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain()); > return javaClass; > } catch(Exception e) { > throw new RuntimeException("Failure during transfer compilation for " + targetClass, e); > } > } > /** Extract setter methods from a class */ > public static Map<String, Method> extractSetters(Class<?> cls) { > Map<String, Method> setters = new HashMap<String, Method>(); > for(Method method : cls.getMethods()) { > // Lookup setter methods > if(method.getName().startsWith("set")) { > // Only public setters > int modifiers = method.getModifiers(); > if(Modifier.isPublic(modifiers)) { > Class<?>[] exceptions = method.getExceptionTypes(); > Class<?>[] parameters = method.getParameterTypes(); > Class<?> returnType = method.getReturnType(); > if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) { > setters.put(method.getName(), method); > } > } > } > } > return setters; > } > } > {noformat} > On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console. > On jdk 9b112, I got the following exception > {noformat} > java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject > at MyTests.compile(MyTests.java:68) > at MyTests.test(MyTests.java:29) > at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) > Caused by: javassist.NotFoundException: java.lang.Object > at javassist.ClassPool.get(ClassPool.java:450) > at MyTests.compile(MyTests.java:51) > ... 24 more > {noformat} > I suspect that is due to the jigsaw integration into the jdk. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-296) Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https://

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-296?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet reassigned WFCORE-296: ---------------------------------------- Assignee: ehsavoie Hugonnet (was: Darran Lofthouse) > Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https:// > --------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-296 > URL: https://issues.jboss.org/browse/WFCORE-296 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI, Domain Management > Reporter: Darran Lofthouse > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Alpha10 > > > From [~dmlloyd] > {quote} > When we have multi-layer protocol going on, the URI scheme we should use > is like this: > outer+middle+inner:// > {quote} > Switch URI schemes from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remote+https:// > The existing schemes will be needed for backwards compatibility but somehow deprecated. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-124) Change switch statements to if/else blocks when translating levels

by James Perkins (JIRA)

James Perkins created JBLOGGING-124: --------------------------------------- Summary: Change switch statements to if/else blocks when translating levels Key: JBLOGGING-124 URL: https://issues.jboss.org/browse/JBLOGGING-124 Project: JBoss Logging Issue Type: Enhancement Reporter: James Perkins Assignee: James Perkins Currently a switch statement is used when levels are translated from a JBoss Logging level to the back end log level. This will likely perform better as an if/else block with the mostly likely used level at the top of the comparison. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBEE-168) Release new version of jboss-annotations-api_1.2_spec

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JBEE-168?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on JBEE-168: ----------------------------------- Where is the upstream repository for synching up with the new 1.3 release source changes? I couldn't open the [http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annot...] link. Our repo for jboss-annotations-api is [https://github.com/jboss/jboss-annotations-api_spec]. [~wolfc], when we release a new jboss-annotations-api_1.3_spec, should we create a new branch for EAP 7.x, so that we have an upstream for EAP 7.x changes to jboss-annotations-api_spec, that is separate from the new EE 8 changes? > Release new version of jboss-annotations-api_1.2_spec > ----------------------------------------------------- > > Key: JBEE-168 > URL: https://issues.jboss.org/browse/JBEE-168 > Project: JBoss JavaEE Spec APIs > Issue Type: Task > Components: jboss-annotations-api > Reporter: Tomas Remes > Assignee: Scott Marlow > > There was new 1.3 release http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annot... recently -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7260) Document in elytron model *-client-auth are mutual exclusive

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-7260: ----------------------------------- In other places (like XNIO) we've historically done an "authentication mode" with three choices: none, want, need. This is a bit more concise and maybe could avoid a bit of user confusion. But Darran is also right: it's not that important as no mode combination is actually invalid per se. > Document in elytron model *-client-auth are mutual exclusive > ------------------------------------------------------------ > > Key: WFLY-7260 > URL: https://issues.jboss.org/browse/WFLY-7260 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Minor > > Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset. > Now we just have: > * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true." > * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext." -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7260) Document in elytron model *-client-auth are mutual exclusive

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-7260: ---------------------------------------- [~honza889] How relevant is this now? If both are set to true then 'need' will always have the highest priority - if one is set to false your latest code within Elytron handles that correctly now. > Document in elytron model *-client-auth are mutual exclusive > ------------------------------------------------------------ > > Key: WFLY-7260 > URL: https://issues.jboss.org/browse/WFLY-7260 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Minor > > Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset. > Now we just have: > * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true." > * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext." -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7260) Document in elytron model *-client-auth are mutual exclusive

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7260: -------------------------------------- Assignee: Jan Kalina (was: Ilia Vassilev) > Document in elytron model *-client-auth are mutual exclusive > ------------------------------------------------------------ > > Key: WFLY-7260 > URL: https://issues.jboss.org/browse/WFLY-7260 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Minor > > Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset. > Now we just have: > * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true." > * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext." -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7150) EJB injection with indirection via web.xml is ignored

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-7150?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-7150: ----------------------------------- Component/s: CDI / Weld Web (Undertow) > EJB injection with indirection via web.xml is ignored > ----------------------------------------------------- > > Key: WFLY-7150 > URL: https://issues.jboss.org/browse/WFLY-7150 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Web (Undertow) > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > If a web application contains a Servlet and a REST service (as CDI Bean) with an @EJB(lookup="java:comp/env/xxxx") injection for a indirection via web.xml/jboss-web.xml the CDI Bean will ignore it without any message whereas the Servlet inject the EJB proxy as expected. > This approach is used to be able to change/adjust the target EJB by changing the DD and not the application code. > Reproducer can be found here: > git@github.com:wfink/jboss-eap-quickstarts.git > BRANCH: 6.4.x_ejb-multi-server_reproducerEJB-injection2 > SubProject: ejb-multi-server (used only a part of it to have a web-app and a ejb-app) > see ejb-multi-server/README-reproducerEJB-injection -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBEE-168) Release new version of jboss-annotations-api_1.2_spec

by Tomas Remes (JIRA)

Tomas Remes created JBEE-168: -------------------------------- Summary: Release new version of jboss-annotations-api_1.2_spec Key: JBEE-168 URL: https://issues.jboss.org/browse/JBEE-168 Project: JBoss JavaEE Spec APIs Issue Type: Task Components: jboss-annotations-api Reporter: Tomas Remes Assignee: Scott Marlow There was new 1.3 release http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annot... recently -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2016