September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBESB-193) Need support for notification generatoin from within ActionProcessor.process method

by Tom Fennelly (JIRA)

Need support for notification generatoin from within ActionProcessor.process method ----------------------------------------------------------------------------------- Key: JBESB-193 URL: http://jira.jboss.com/jira/browse/JBESB-193 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.1 Reporter: Tom Fennelly Assigned To: Mark Little Fix For: 4.1 In version 4.0, the Action Processing pipeline management code raises notifications in response to an exception from the ActionProcessor.process method. The pipeline managemnt code calls the getOkNotification (no exception) or getErrorNotification (exception) to get the notification message. For many reasons, this is a very flawed model. Notifications should be raised from within the process method by means of attaching the notifications (error or otherwise) to the message (the mechanism is a design issue). Once the process method returns, the pipline processing management code can check the message for notifications. If there are errors, it can/should (?) abort the message processing, send the error notification (by whatever notification options are configured on the listener) and signal the failure to the calling process (by whatever failure config is configured on the listener). The getOk and getErro methods can then be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

6 months, 1 week

3
6
0 / 0

[JBoss JIRA] Created: (JGRP-1257) ENCRYPT protocol UnrecoverableKeyException: Given final block not properly padded

by Andres Garcia Garcia (JIRA)

ENCRYPT protocol UnrecoverableKeyException: Given final block not properly padded --------------------------------------------------------------------------------- Key: JGRP-1257 URL: https://jira.jboss.org/browse/JGRP-1257 Project: JGroups Issue Type: Bug Affects Versions: 2.11, 2.8, 2.7 Environment: Windows XP SP3, Java 1.6 Reporter: Andres Garcia Garcia Assignee: Bela Ban Recently I updated my jgroups version from 2.4.x to 2.11. Suddenly my applications thrown this exception. org.jgroups.ChannelException: unable to setup the protocol stack: Given final block not properly padded at org.jgroups.JChannel.init(JChannel.java:1574) at org.jgroups.JChannel.<init>(JChannel.java:257) at org.jgroups.JChannel.<init>(JChannel.java:240) at org.jgroups.demos.Draw.<init>(Draw.java:52) at org.jgroups.demos.Draw.main(Draw.java:141) Caused by: java.security.UnrecoverableKeyException: Given final block not properly padded at com.sun.crypto.provider.SunJCE_z.a(DashoA13*..) at com.sun.crypto.provider.JceKeyStore.engineGetKey(DashoA13*..) at java.security.KeyStore.getKey(Unknown Source) at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:269) at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:231) at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:641) at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:468) at org.jgroups.JChannel.init(JChannel.java:1570) ... 4 more The ENCRYPT protocol config is <ENCRYPT sym_init="448" sym_algorithm="Blowfish" encrypt_entire_message="true" key_store_name="cloudencrypt.keystore" store_password="password" alias="test"/> I tested the same code with different versions. 2.6.15 GA is the last working version, and every version I tested from 2.7 GA to 2.11 GA throw the same exception. I made a little use case with it. Maybe I am missing something? -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

6 months, 1 week

3
9
0 / 0

[JBoss JIRA] Created: (AS7-782) Hudson/Jenkins won't work in AS7b3

by Fred Bricon (JIRA)

Hudson/Jenkins won't work in AS7b3 ---------------------------------- Key: AS7-782 URL: https://issues.jboss.org/browse/AS7-782 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.0.0.Beta3 Environment: Fedora 14, JDK 1.6.0_24, JBoss AS7 beta 3 Reporter: Fred Bricon Assignee: Jason Greene After patching AS7b3 with the latest jboss-vfs from github/master and deploying hudson ( http://search.maven.org/remotecontent?filepath=org/jvnet/hudson/main/huds...) or jenkins on AS7, an exception is thrown when accessing the homepage (or any page) : {noformat} 17:39:33,429 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/hudson-war-2.0.0].[Stapler]] (http-localhost.localdomain-127.0.0.1-8080-2) "Servlet.service()" pour la servlet Stapler a généré une exception: java.net.MalformedURLException: unknown protocol: jndi at java.net.URL.<init>(URL.java:574) [:1.6.0_24] at java.net.URL.<init>(URL.java:464) [:1.6.0_24] at java.net.URL.<init>(URL.java:413) [:1.6.0_24] at org.kohsuke.stapler.Stapler.selectResourceByLocale(Stapler.java:227) [stapler-1.155.jar:] at org.kohsuke.stapler.Stapler.openResourcePathByLocale(Stapler.java:203) [stapler-1.155.jar:] at org.kohsuke.stapler.Stapler.service(Stapler.java:145) [stapler-1.155.jar:] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:94) [hudson-core-2.0.0.jar:] at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:86) [hudson-core-2.0.0.jar:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) [hudson-core-2.0.0.jar:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:162) [hudson-core-2.0.0.jar:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) [hudson-core-2.0.0.jar:] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:388) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:658) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3] at java.lang.Thread.run(Thread.java:662) [:1.6.0_24] {noformat} I first mentioned this issur on irc (see http://echelog.matzon.dk/logs/browse/jboss-as7/1305151200 [13:42:43] -> [13:48:58]) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

6 months, 2 weeks

6
7
0 / 0

[JBoss JIRA] Created: (JBFORUMS-109) BBCode support for standalone version

by Ryszard Kozmik (JIRA)

BBCode support for standalone version ------------------------------------- Key: JBFORUMS-109 URL: http://jira.jboss.com/jira/browse/JBFORUMS-109 Project: JBoss Forums Issue Type: Task Components: Forum Enhancements Reporter: Ryszard Kozmik Fix For: 1.0.0 Alpha BBCode parser is now working only in portal environment. We need make it work as a standalone too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

8 months

4
5
0 / 0

[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender

by Bela Ban (JIRA)

Optimization: make threads return immediately if NAKACK has another active thread for the same sender ----------------------------------------------------------------------------------------------------- Key: JGRP-457 URL: http://jira.jboss.com/jira/browse/JGRP-457 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5 In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up. If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock. The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

9 months, 2 weeks

2
3
0 / 0

[JBoss JIRA] (JBRULES-3445) DSL expander expands lines in /* */comment block

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3445: ------------------------------------ Summary: DSL expander expands lines in /* */comment block Key: JBRULES-3445 URL: https://issues.jboss.org/browse/JBRULES-3445 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco When you comment some code in dslr file, the expander still tries to expand it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

1 year, 3 months

3
10
0 / 0

[JBoss JIRA] (WFCORE-1845) Logging subsystem scans the CWD on server boot

by Brent Douglas (JIRA)

Brent Douglas created WFCORE-1845: ------------------------------------- Summary: Logging subsystem scans the CWD on server boot Key: WFCORE-1845 URL: https://issues.jboss.org/browse/WFCORE-1845 Project: WildFly Core Issue Type: Feature Request Components: Logging Affects Versions: 2.0.10.Final Environment: OSX El Capitan, Oracle JDK 1.8.0_92 && 101, swarm 2016.8.1, WF 10.0.0.Final, WF-CORE 2.0.10.Final Reporter: Brent Douglas Assignee: James Perkins When booting the server from a directory where the subtree is large the server hangs for a long time. JStack shows that the logging subsystem is scanning the CWD. Booting the server from the root dir of a maven parent project containing 2 subprojects, a swarm project and a small NPM subproject added 33s to the server boot time compared to stepping into the swarm project and booting it. Stacktrace while the server is booting: {noformat} Thread 25859: (state = IN_NATIVE) - sun.nio.fs.UnixNativeDispatcher.lstat0(long, sun.nio.fs.UnixFileAttributes) @bci=0 (Compiled frame; information may be imprecise) - sun.nio.fs.UnixNativeDispatcher.lstat(sun.nio.fs.UnixPath, sun.nio.fs.UnixFileAttributes) @bci=10, line=300 (Compiled frame) - sun.nio.fs.UnixFileAttributes.get(sun.nio.fs.UnixPath, boolean) @bci=22, line=72 (Compiled frame) - sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes() @bci=15, line=52 (Compiled frame) - sun.nio.fs.UnixFileSystemProvider.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=57, line=144 (Compiled frame) - java.nio.file.Files.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=7, line=1737 (Compiled frame) - java.nio.file.FileTreeWalker.getAttributes(java.nio.file.Path, boolean) @bci=56, line=219 (Compiled frame) - java.nio.file.FileTreeWalker.visit(java.nio.file.Path, boolean, boolean) @bci=3, line=276 (Compiled frame) - java.nio.file.FileTreeWalker.next() @bci=134, line=372 (Compiled frame) - java.nio.file.Files.walkFileTree(java.nio.file.Path, java.util.Set, int, java.nio.file.FileVisitor) @bci=256, line=2706 (Compiled frame) - java.nio.file.Files.walkFileTree(java.nio.file.Path, java.nio.file.FileVisitor) @bci=9, line=2742 (Interpreted frame) - org.jboss.as.logging.LoggingResource.findFiles(java.lang.String, org.jboss.dmr.ModelNode, boolean) @bci=47, line=251 (Interpreted frame) - org.jboss.as.logging.LoggingResource.getChildrenNames(java.lang.String) @bci=37, line=157 (Interpreted frame) - org.jboss.as.logging.LoggingResource.getChildren(java.lang.String) @bci=11, line=171 (Interpreted frame) - org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(java.lang.String) @bci=5, line=362 (Interpreted frame) - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=99, line=289 (Interpreted frame) - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame) - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame) - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=189, line=291 (Interpreted frame) - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame) - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame) - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource) @bci=2, line=250 (Interpreted frame) - org.jboss.as.controller.ModelControllerImpl.writeModel(org.jboss.as.controller.ModelControllerImpl$ManagementModelImpl, java.util.Set) @bci=19, line=769 (Interpreted frame) - org.jboss.as.controller.OperationContextImpl.createPersistenceResource() @bci=17, line=519 (Interpreted frame) - org.jboss.as.controller.AbstractOperationContext.executeDoneStage(org.jboss.dmr.ModelNode) @bci=22, line=708 (Interpreted frame) - org.jboss.as.controller.AbstractOperationContext.processStages() @bci=277, line=680 (Interpreted frame) - org.jboss.as.controller.AbstractOperationContext.executeOperation() @bci=27, line=370 (Interpreted frame) - org.jboss.as.controller.OperationContextImpl.executeOperation() @bci=20, line=1344 (Interpreted frame) - org.jboss.as.controller.ModelControllerImpl.boot(java.util.List, org.jboss.as.controller.client.OperationMessageHandler, org.jboss.as.controller.ModelController$OperationTransactionControl, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider, boolean, boolean) @bci=410, line=485 (Interpreted frame) - org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider) @bci=16, line=387 (Interpreted frame) - org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean) @bci=7, line=349 (Interpreted frame) - org.jboss.as.server.ServerService.boot(java.util.List, boolean) @bci=22, line=392 (Interpreted frame) - org.jboss.as.server.ServerService.boot(org.jboss.as.controller.BootContext) @bci=907, line=365 (Interpreted frame) - org.jboss.as.controller.AbstractControllerService$1.run() @bci=12, line=299 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame) {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1844) RemoteProxyController can block indefinitely trying to cancel a timed out operation

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-1844: ---------------------------------------- Summary: RemoteProxyController can block indefinitely trying to cancel a timed out operation Key: WFCORE-1844 URL: https://issues.jboss.org/browse/WFCORE-1844 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Trying to execute management requests against a managed domain server that is unresponsive due to OOME results in threads on the HC in stuck permanently in a state like this: {code} "Host Controller Service Threads - 48" #91 prio=5 os_prio=31 tid=0x00007fbbf0039800 nid=0x3d33 in Object.wait() [0x0000700003c42000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000007b64842d0> (a org.jboss.as.protocol.mgmt.ActiveOperationImpl) at java.lang.Object.wait(Object.java:502) at org.jboss.threads.AsyncFutureTask.awaitUninterruptibly(AsyncFutureTask.java:221) - locked <0x00000007b64842d0> (a org.jboss.as.protocol.mgmt.ActiveOperationImpl) at org.jboss.as.controller.client.impl.BasicDelegatingAsyncFuture.awaitUninterruptibly(BasicDelegatingAsyncFuture.java:57) at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.awaitUninterruptibly(AbstractDelegatingAsyncFuture.java:35) at org.jboss.as.controller.client.impl.BasicDelegatingAsyncFuture.cancel(BasicDelegatingAsyncFuture.java:74) at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.cancel(AbstractDelegatingAsyncFuture.java:35) at org.jboss.as.controller.remote.RemoteProxyController.execute(RemoteProxyController.java:173) at org.jboss.as.controller.TransformingProxyController$Factory$TransformingProxyControllerImpl.execute(TransformingProxyController.java:203) at org.jboss.as.controller.ProxyStepHandler.execute(ProxyStepHandler.java:170) {code} The RemoteProxyController code looks like this: {code} long timeout = blockingTimeout.getProxyBlockingTimeout(targetAddress, this); prepared = queue.poll(timeout, TimeUnit.MILLISECONDS); if (prepared == null) { blockingTimeout.proxyTimeoutDetected(targetAddress); futureResult.cancel(true); {code} The problem is that "cancel" call will block, uninterruptibly, until the remote process responds to the cancel message. Which it won't do, as it's all messed up from the OOME condition. Hopefully this can be simply fixed by converting that call to asyncCancel. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-522) Add callbacks for persisting and restoring a SecurityIdentity

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-522?page=com.atlassian.jira.plugin.sy... ] Pedro Igor commented on ELY-522: -------------------------------- [~darranl], can we close this issue in favor of https://issues.jboss.org/browse/ELY-624 ? > Add callbacks for persisting and restoring a SecurityIdentity > ------------------------------------------------------------- > > Key: ELY-522 > URL: https://issues.jboss.org/browse/ELY-522 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-522) Add callbacks for persisting and restoring a SecurityIdentity

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-522?page=com.atlassian.jira.plugin.sy... ] Pedro Igor edited comment on ELY-522 at 9/30/16 4:53 PM: --------------------------------------------------------- [~darranl], can we close this issue now that https://issues.jboss.org/browse/ELY-624 is merged ? was (Author: pcraveiro): [~darranl], can we close this issue in favor of https://issues.jboss.org/browse/ELY-624 ? > Add callbacks for persisting and restoring a SecurityIdentity > ------------------------------------------------------------- > > Key: ELY-522 > URL: https://issues.jboss.org/browse/ELY-522 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-628) Allow JWT-based token realms to operate in parse-only mode

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-628?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-628: --------------------------- Fix Version/s: 1.1.0.Beta10 (was: 1.1.0.Beta11) > Allow JWT-based token realms to operate in parse-only mode > ---------------------------------------------------------- > > Key: ELY-628 > URL: https://issues.jboss.org/browse/ELY-628 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.1.0.Beta8 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-624) Add support for SSO and Clustered SSO

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-624?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-624: --------------------------- Fix Version/s: 1.1.0.Beta10 (was: 1.1.0.Beta11) > Add support for SSO and Clustered SSO > ------------------------------------- > > Key: ELY-624 > URL: https://issues.jboss.org/browse/ELY-624 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta10 > > > This issue is to cover the APIs / SPIs and some implementation where Elytron is to be used with container managed SSO / Clustered SSO. > By this we mean authentication mechanisms similar to HTTP Form where we want the resulting SecurityIdentity to be re-used across different HTTP context and possibly in the clustered case across different nodes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-650) Improvements to Elytron Web and Undertow Testsuite

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-650?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-650: --------------------------- Summary: Improvements to Elytron Web and Undertow Testsuite (was: Improvements to elytron-web testsuite) > Improvements to Elytron Web and Undertow Testsuite > -------------------------------------------------- > > Key: ELY-650 > URL: https://issues.jboss.org/browse/ELY-650 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Affects Versions: 1.1.0.Beta10 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-650) Improvements to elytron-web testsuite

by Pedro Igor (JIRA)

Pedro Igor created ELY-650: ------------------------------ Summary: Improvements to elytron-web testsuite Key: ELY-650 URL: https://issues.jboss.org/browse/ELY-650 Project: WildFly Elytron Issue Type: Enhancement Components: HTTP Affects Versions: 1.1.0.Beta10 Reporter: Pedro Igor Assignee: Darran Lofthouse Fix For: 1.1.0.Beta11 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-650) Improvements to elytron-web testsuite

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-650?page=com.atlassian.jira.plugin.sy... ] Pedro Igor reassigned ELY-650: ------------------------------ Assignee: Pedro Igor (was: Darran Lofthouse) > Improvements to elytron-web testsuite > ------------------------------------- > > Key: ELY-650 > URL: https://issues.jboss.org/browse/ELY-650 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Affects Versions: 1.1.0.Beta10 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1842) Support RBAC based on raw roles from an Identity

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1842?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-1842: ------------------------------------------ +1 we removed useRealmRoles as it was confusing in the context of the legacy security realms - now the roles are available from an Elytron SecurityIdentity making it possible to enable a default 1:1 mapping makes sense again. > Support RBAC based on raw roles from an Identity > ------------------------------------------------- > > Key: WFCORE-1842 > URL: https://issues.jboss.org/browse/WFCORE-1842 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Pedro Igor > Assignee: Darran Lofthouse > > Currently, RBAC requires a static mapping between standard roles and raw roles from an identity. > We should be able to use RBAC without necessarily forcing this static mapping and just consider the raw roles from the identity. > This issue may be related with exposing {{org.jboss.as.controller.access.management.WritableAuthorizerConfiguration#useRealmRoles}} in the management model. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1842) Support RBAC based on raw roles from an Identity

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1842?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-1842: ---------------------------------------- Assignee: Darran Lofthouse > Support RBAC based on raw roles from an Identity > ------------------------------------------------- > > Key: WFCORE-1842 > URL: https://issues.jboss.org/browse/WFCORE-1842 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Pedro Igor > Assignee: Darran Lofthouse > > Currently, RBAC requires a static mapping between standard roles and raw roles from an identity. > We should be able to use RBAC without necessarily forcing this static mapping and just consider the raw roles from the identity. > This issue may be related with exposing {{org.jboss.as.controller.access.management.WritableAuthorizerConfiguration#useRealmRoles}} in the management model. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-482?page=com.atlassian.jira.plugin... ] James Perkins commented on WFCORE-482: -------------------------------------- This is something I've started working on. Currently I'm just implementing a log4j2 {{LoggerContextFactory}} which uses a {{org.jboss.logmanager.Logger}}. If anyone has some example uses cases of how they use log4j2 that would be helpful. Some questions that would be helpful to know the answer to: # Do you just use the log4j2-api? # Do you use a custom {{LoggerContextFactory}}? # Are you using system properties or a properties file to configure log4j2? # Are you using the log4j-web dependency? Any other comments on how you're using log4j2 in WildFly or any container would be helpful. Thanks in advance! > Add log4j2 support for WildFly > ------------------------------ > > Key: WFCORE-482 > URL: https://issues.jboss.org/browse/WFCORE-482 > Project: WildFly Core > Issue Type: Task > Components: Logging > Environment: Spring 3, Hibernate, Wicket, JBoss AS7 > Reporter: Amarkanth Ranganamayna > Assignee: James Perkins > Priority: Optional > > I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2. > Looks like Jboss AS7 by default use log4j 1.x > Are you guys already working on using log4j2 ? > If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging. > Thanks, > Amar -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management

by Bill Tuminaro (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ] Bill Tuminaro commented on DROOLS-1313: --------------------------------------- I added some System.gc() calls after the updateToVersion() calls, they do not seem to have any affect. > Memory Leak - but is this a supported scenario for Dynamic rule management > -------------------------------------------------------------------------- > > Key: DROOLS-1313 > URL: https://issues.jboss.org/browse/DROOLS-1313 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Bill Tuminaro > Assignee: Mario Fusco > Attachments: SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG > > > I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/). > However, I am not sure this is a supported scenario. If this is a supported approach this needs to get fixed, otherwise we need to use another approach. > The attached source does this: > +*Initialize stuff*+ > - Create a new ReleaseId > - Create a new KieFileSystem > - Generate and write the PomXML for the ReleaseId created above > - Create a new KieModuleModel > - Create a new KieBaseModel > - Write the ModuleModel XML to the KieFileSystem > - Write 2 rules into the KieFileSystem > +*1st build and dump*+ > - Create a new KieBuilder > - Do a buildall() with the KieBuilder > - Create a new KieContainer > - Create a new KieSession from the KieContainer > - Print out the rules in the KieContainer for the package used in my rules > - Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected. > +*2nd build and dump*+ > - Delete 2 rules from the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Add 2 new rules to the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Print out the rules in the KieContainer for the package used in my rules > - Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png. > - Rule_120_Triggered_Part_1_ 0 is not there > - Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak) > +*3rd build and dump*+ > - Delete 1 rule from the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Add 2 new rules to the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Print out the rules in the KieContainer for the package used in my rules > - Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png. > - Rule_120_Triggered_Part_1_ 0 is STILL not there > - TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak) > - Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1842) Support RBAC based on raw roles from an Identity

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1842?page=com.atlassian.jira.plugi... ] Pedro Igor commented on WFCORE-1842: ------------------------------------ Nope. Accordingly with [~darranl], we just need to get it back and keep original behavior. > Support RBAC based on raw roles from an Identity > ------------------------------------------------- > > Key: WFCORE-1842 > URL: https://issues.jboss.org/browse/WFCORE-1842 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Pedro Igor > > Currently, RBAC requires a static mapping between standard roles and raw roles from an identity. > We should be able to use RBAC without necessarily forcing this static mapping and just consider the raw roles from the identity. > This issue may be related with exposing {{org.jboss.as.controller.access.management.WritableAuthorizerConfiguration#useRealmRoles}} in the management model. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1842) Support RBAC based on raw roles from an Identity

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1842?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1842: ------------------------------------------ Is this a proposal to do anything beyond what the original useRealmRoles did? > Support RBAC based on raw roles from an Identity > ------------------------------------------------- > > Key: WFCORE-1842 > URL: https://issues.jboss.org/browse/WFCORE-1842 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Pedro Igor > > Currently, RBAC requires a static mapping between standard roles and raw roles from an identity. > We should be able to use RBAC without necessarily forcing this static mapping and just consider the raw roles from the identity. > This issue may be related with exposing {{org.jboss.as.controller.access.management.WritableAuthorizerConfiguration#useRealmRoles}} in the management model. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7247) Wildfly 10 JSESSIONIDSSOs not being created

by M Wardell (JIRA)

M Wardell created WFLY-7247: ------------------------------- Summary: Wildfly 10 JSESSIONIDSSOs not being created Key: WFLY-7247 URL: https://issues.jboss.org/browse/WFLY-7247 Project: WildFly Issue Type: Bug Affects Versions: 10.1.0.Final, 10.0.0.Final Reporter: M Wardell Assignee: Jason Greene Found on wildfly 10.1 and 10.0. With SSO enabled, the server can startup in a state where not all the deployments get the SSO auth mechanism. Possibly caused by a missing dependency between the UndertowDeploymentInfoService and SingleSignOnService, which could be allowing the deployments to start before the SSO auth mechanism is registered in the host service. Issue in intermittent on startup. After most startups the JESSSIONIDSSO is reliably generated during login. After some startups the JSESSIONIDSSO is never created after login. Details in the referenced forum thread. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1335) Add protection in RaXmlDeployer to prevent from loading xml resource

by COLLIGNON Thomas (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1335?page=com.atlassian.jira.plugin... ] COLLIGNON Thomas commented on JBJCA-1335: ----------------------------------------- Same things here : https://issues.jboss.org/browse/JBJCA-1333 > Add protection in RaXmlDeployer to prevent from loading xml resource > -------------------------------------------------------------------- > > Key: JBJCA-1335 > URL: https://issues.jboss.org/browse/JBJCA-1335 > Project: IronJacamar > Issue Type: Enhancement > Components: Deployer > Affects Versions: 1.2.7.Final > Reporter: COLLIGNON Thomas > Priority: Minor > Fix For: 1.2.8.Final > > > If we place a -ra.xml in jar file, the class RaXmlDeployer will fail with "URI not hierarchical error", because it doesn't handle jar file. > The goal of this issue is prevent for loading jar file in RaXmlDeployer . > The second goal is to provide ability of overring RaXmlDeployer in custom deployer who extends this class. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1335) Add protection in RaXmlDeployer to prevent from loading xml resource

by COLLIGNON Thomas (JIRA)

COLLIGNON Thomas created JBJCA-1335: --------------------------------------- Summary: Add protection in RaXmlDeployer to prevent from loading xml resource Key: JBJCA-1335 URL: https://issues.jboss.org/browse/JBJCA-1335 Project: IronJacamar Issue Type: Enhancement Components: Deployer Affects Versions: 1.2.7.Final Reporter: COLLIGNON Thomas Priority: Minor Fix For: 1.2.8.Final If we place a -ra.xml in jar file, the class RaXmlDeployer will fail with "URI not hierarchical error", because it doesn't handle jar file. The goal of this issue is prevent for loading jar file in RaXmlDeployer . The second goal is to provide ability of overring RaXmlDeployer in custom deployer who extends this class. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1843) As a user I can specify export dependencies while creating/maintaining JBoss modules within CLI

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1843?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1843: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1842 > As a user I can specify export dependencies while creating/maintaining JBoss modules within CLI > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-1843 > URL: https://issues.jboss.org/browse/WFCORE-1843 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > In order to export some dependencies, the module add command should offer a new option to identify modules to export. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2102 at 9/30/16 10:56 AM: ---------------------------------------------------------- I cannot reproduce this, and I'm not sure I understand what you're describing. I suggest drop {{bind_interface}} and only use {{bind_addr}}, e.g. {{bind_addr="match-interface:eth0"}}. The {{bind_interface}} attribute was removed in 4.0 anyway. was (Author: belaban): I cannot reproduce this, and I'm not sure I understand what you're describing. I suggest drop {{bind_interface}} and only use {{bind_addr}}, e.g. {{ bind_addr="match-interface:eth0"}}. The {{bind_interface}} attribute was removed in 4.0 anyway. > bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict > -------------------------------------------------------------------- > > Key: JGRP-2102 > URL: https://issues.jboss.org/browse/JGRP-2102 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.1 > Environment: {noformat} > [root@wtc2k01v27 ~] CLONE # ip a > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 2606:ae00:e200:3f::83/128 scope global > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 > link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff > inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0 > inet6 2606:ae00:e200:3f::28/64 scope global > valid_lft forever preferred_lft forever > inet6 fe80::250:56ff:feab:2aea/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 > link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff > inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1 > inet6 fe80::250:56ff:feab:d612/64 scope link > valid_lft forever preferred_lft forever > {noformat} > There're eth0 and eth1 exists in the environment > Reporter: 俐佳张 > Assignee: Bela Ban > Fix For: 3.6.12 > > Attachments: jgroups-udp.xml > > > Error happens while > Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56) > at java.lang.reflect.Method.invoke(Method.java:620) > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) > at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) > at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) > at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) > at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226) > ... 26 more > Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned > at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153) > at org.jgroups.stack.Configurator.createLayer(Configurator.java:444) > at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398) > at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90) > at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57) > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477) > at org.jgroups.JChannel.init(JChannel.java:854) > at org.jgroups.JChannel.<init>(JChannel.java:159) > at org.jgroups.JChannel.<init>(JChannel.java:129) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404) > ... 39 more > Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed > at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84) > at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147) > ... 48 more > Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3 > at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132) > bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time > but it couldn't get the eth0 link local address but return eth1 link local address > This code return the first address that match, it should return with eth0 > jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java > {code} > public static InetAddress getAddress(AddressScope scope) // ----> scope is LINK_LOCAL > throws SocketException > { > InetAddress address = null; > Enumeration intfs = NetworkInterface.getNetworkInterfaces(); > while (intfs.hasMoreElements()) { > NetworkInterface intf = (NetworkInterface)intfs.nextElement(); > try { > if (intf.isUp()) { > address = getAddress(intf, scope); // -------> It will return the first LINK_LOCAL address from NICs list > if (address != null) > return address; > } > } > catch (SocketException e) { > } > } > return null; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2102: -------------------------------- I cannot reproduce this, and I'm not sure I understand what you're describing. I suggest drop {{bind_interface}} and only use {{bind_addr}}, e.g. {{ bind_addr="match-interface:eth0"}}. The {{bind_interface}} attribute was removed in 4.0 anyway. > bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict > -------------------------------------------------------------------- > > Key: JGRP-2102 > URL: https://issues.jboss.org/browse/JGRP-2102 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.1 > Environment: {noformat} > [root@wtc2k01v27 ~] CLONE # ip a > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 2606:ae00:e200:3f::83/128 scope global > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 > link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff > inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0 > inet6 2606:ae00:e200:3f::28/64 scope global > valid_lft forever preferred_lft forever > inet6 fe80::250:56ff:feab:2aea/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 > link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff > inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1 > inet6 fe80::250:56ff:feab:d612/64 scope link > valid_lft forever preferred_lft forever > {noformat} > There're eth0 and eth1 exists in the environment > Reporter: 俐佳张 > Assignee: Bela Ban > Fix For: 3.6.12 > > Attachments: jgroups-udp.xml > > > Error happens while > Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56) > at java.lang.reflect.Method.invoke(Method.java:620) > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) > at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) > at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) > at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) > at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226) > ... 26 more > Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned > at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153) > at org.jgroups.stack.Configurator.createLayer(Configurator.java:444) > at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398) > at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90) > at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57) > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477) > at org.jgroups.JChannel.init(JChannel.java:854) > at org.jgroups.JChannel.<init>(JChannel.java:159) > at org.jgroups.JChannel.<init>(JChannel.java:129) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404) > ... 39 more > Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed > at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84) > at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147) > ... 48 more > Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3 > at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132) > bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time > but it couldn't get the eth0 link local address but return eth1 link local address > This code return the first address that match, it should return with eth0 > jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java > {code} > public static InetAddress getAddress(AddressScope scope) // ----> scope is LINK_LOCAL > throws SocketException > { > InetAddress address = null; > Enumeration intfs = NetworkInterface.getNetworkInterfaces(); > while (intfs.hasMoreElements()) { > NetworkInterface intf = (NetworkInterface)intfs.nextElement(); > try { > if (intf.isUp()) { > address = getAddress(intf, scope); // -------> It will return the first LINK_LOCAL address from NICs list > if (address != null) > return address; > } > } > catch (SocketException e) { > } > } > return null; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2102: --------------------------- Environment: {noformat} [root@wtc2k01v27 ~] CLONE # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 2606:ae00:e200:3f::83/128 scope global valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0 inet6 2606:ae00:e200:3f::28/64 scope global valid_lft forever preferred_lft forever inet6 fe80::250:56ff:feab:2aea/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1 inet6 fe80::250:56ff:feab:d612/64 scope link valid_lft forever preferred_lft forever {noformat} There're eth0 and eth1 exists in the environment was: [root@wtc2k01v27 ~] CLONE # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 2606:ae00:e200:3f::83/128 scope global valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0 inet6 2606:ae00:e200:3f::28/64 scope global valid_lft forever preferred_lft forever inet6 fe80::250:56ff:feab:2aea/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1 inet6 fe80::250:56ff:feab:d612/64 scope link valid_lft forever preferred_lft forever There're eth0 and eth1 exists in the environment > bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict > -------------------------------------------------------------------- > > Key: JGRP-2102 > URL: https://issues.jboss.org/browse/JGRP-2102 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.1 > Environment: {noformat} > [root@wtc2k01v27 ~] CLONE # ip a > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 2606:ae00:e200:3f::83/128 scope global > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 > link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff > inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0 > inet6 2606:ae00:e200:3f::28/64 scope global > valid_lft forever preferred_lft forever > inet6 fe80::250:56ff:feab:2aea/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 > link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff > inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1 > inet6 fe80::250:56ff:feab:d612/64 scope link > valid_lft forever preferred_lft forever > {noformat} > There're eth0 and eth1 exists in the environment > Reporter: 俐佳张 > Assignee: Bela Ban > Fix For: 3.6.12 > > Attachments: jgroups-udp.xml > > > Error happens while > Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56) > at java.lang.reflect.Method.invoke(Method.java:620) > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) > at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) > at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) > at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) > at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226) > ... 26 more > Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned > at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153) > at org.jgroups.stack.Configurator.createLayer(Configurator.java:444) > at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398) > at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90) > at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57) > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477) > at org.jgroups.JChannel.init(JChannel.java:854) > at org.jgroups.JChannel.<init>(JChannel.java:159) > at org.jgroups.JChannel.<init>(JChannel.java:129) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404) > ... 39 more > Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed > at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84) > at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147) > ... 48 more > Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3 > at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132) > bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time > but it couldn't get the eth0 link local address but return eth1 link local address > This code return the first address that match, it should return with eth0 > jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java > {code} > public static InetAddress getAddress(AddressScope scope) // ----> scope is LINK_LOCAL > throws SocketException > { > InetAddress address = null; > Enumeration intfs = NetworkInterface.getNetworkInterfaces(); > while (intfs.hasMoreElements()) { > NetworkInterface intf = (NetworkInterface)intfs.nextElement(); > try { > if (intf.isUp()) { > address = getAddress(intf, scope); // -------> It will return the first LINK_LOCAL address from NICs list > if (address != null) > return address; > } > } > catch (SocketException e) { > } > } > return null; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2102: --------------------------- Description: Error happens while Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56) at java.lang.reflect.Method.invoke(Method.java:620) at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226) ... 26 more Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153) at org.jgroups.stack.Configurator.createLayer(Configurator.java:444) at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398) at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90) at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57) at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477) at org.jgroups.JChannel.init(JChannel.java:854) at org.jgroups.JChannel.<init>(JChannel.java:159) at org.jgroups.JChannel.<init>(JChannel.java:129) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404) ... 39 more Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84) at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147) ... 48 more Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3 at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time but it couldn't get the eth0 link local address but return eth1 link local address This code return the first address that match, it should return with eth0 jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java {code} public static InetAddress getAddress(AddressScope scope) // ----> scope is LINK_LOCAL throws SocketException { InetAddress address = null; Enumeration intfs = NetworkInterface.getNetworkInterfaces(); while (intfs.hasMoreElements()) { NetworkInterface intf = (NetworkInterface)intfs.nextElement(); try { if (intf.isUp()) { address = getAddress(intf, scope); // -------> It will return the first LINK_LOCAL address from NICs list if (address != null) return address; } } catch (SocketException e) { } } return null; } {code} was: Error happens while Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56) at java.lang.reflect.Method.invoke(Method.java:620) at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226) ... 26 more Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153) at org.jgroups.stack.Configurator.createLayer(Configurator.java:444) at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398) at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90) at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57) at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477) at org.jgroups.JChannel.init(JChannel.java:854) at org.jgroups.JChannel.<init>(JChannel.java:159) at org.jgroups.JChannel.<init>(JChannel.java:129) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404) ... 39 more Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84) at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147) ... 48 more Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3 at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time but it couldn't get the eth0 link local address but return eth1 link local address This code return the first address that match, it should return with eth0 jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL throws SocketException { InetAddress address = null; Enumeration intfs = NetworkInterface.getNetworkInterfaces(); while (intfs.hasMoreElements()) { NetworkInterface intf = (NetworkInterface)intfs.nextElement(); try { if (intf.isUp()) { address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list if (address != null) return address; } } catch (SocketException e) { } } return null; } > bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict > -------------------------------------------------------------------- > > Key: JGRP-2102 > URL: https://issues.jboss.org/browse/JGRP-2102 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.1 > Environment: [root@wtc2k01v27 ~] CLONE # ip a > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 2606:ae00:e200:3f::83/128 scope global > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 > link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff > inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0 > inet6 2606:ae00:e200:3f::28/64 scope global > valid_lft forever preferred_lft forever > inet6 fe80::250:56ff:feab:2aea/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 > link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff > inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1 > inet6 fe80::250:56ff:feab:d612/64 scope link > valid_lft forever preferred_lft forever > There're eth0 and eth1 exists in the environment > Reporter: 俐佳张 > Assignee: Bela Ban > Fix For: 3.6.12 > > Attachments: jgroups-udp.xml > > > Error happens while > Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56) > at java.lang.reflect.Method.invoke(Method.java:620) > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) > at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) > at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) > at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) > at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226) > ... 26 more > Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned > at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153) > at org.jgroups.stack.Configurator.createLayer(Configurator.java:444) > at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398) > at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90) > at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57) > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477) > at org.jgroups.JChannel.init(JChannel.java:854) > at org.jgroups.JChannel.<init>(JChannel.java:159) > at org.jgroups.JChannel.<init>(JChannel.java:129) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404) > ... 39 more > Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed > at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84) > at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147) > ... 48 more > Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3 > at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132) > bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time > but it couldn't get the eth0 link local address but return eth1 link local address > This code return the first address that match, it should return with eth0 > jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java > {code} > public static InetAddress getAddress(AddressScope scope) // ----> scope is LINK_LOCAL > throws SocketException > { > InetAddress address = null; > Enumeration intfs = NetworkInterface.getNetworkInterfaces(); > while (intfs.hasMoreElements()) { > NetworkInterface intf = (NetworkInterface)intfs.nextElement(); > try { > if (intf.isUp()) { > address = getAddress(intf, scope); // -------> It will return the first LINK_LOCAL address from NICs list > if (address != null) > return address; > } > } > catch (SocketException e) { > } > } > return null; > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1843) As a user I can specify export dependencies while creating/maintaining JBoss modules within CLI

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1843?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-1843: ----------------------------------------- Description: In order to export some dependencies, the module add command should offer a new option to identify modules to export. > As a user I can specify export dependencies while creating/maintaining JBoss modules within CLI > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-1843 > URL: https://issues.jboss.org/browse/WFCORE-1843 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > In order to export some dependencies, the module add command should offer a new option to identify modules to export. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1843) As a user I can specify export dependencies while creating/maintaining JBoss modules within CLI

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-1843: -------------------------------------------- Summary: As a user I can specify export dependencies while creating/maintaining JBoss modules within CLI Key: WFCORE-1843 URL: https://issues.jboss.org/browse/WFCORE-1843 Project: WildFly Core Issue Type: Feature Request Components: CLI Reporter: Jean-Francois Denise -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1843) As a user I can specify export dependencies while creating/maintaining JBoss modules within CLI

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1843?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-1843: -------------------------------------------- Assignee: Jean-Francois Denise > As a user I can specify export dependencies while creating/maintaining JBoss modules within CLI > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-1843 > URL: https://issues.jboss.org/browse/WFCORE-1843 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-7229: ------------------------------------ [~micnowak1] There are a number of reasons why invalidating a session via a rogue thread is a bad idea. # If the session is later accessed by another node, the thread initiated on the first node will still expire the session # Undeploy of the application will not kill threads started in this way, thus your application will leak its classloader > WFLYCLWEBUT0001 for server-side invalidated sessions > ---------------------------------------------------- > > Key: WFLY-7229 > URL: https://issues.jboss.org/browse/WFLY-7229 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes. > Reporter: Michał Nowakowski > Assignee: Paul Ferraro > Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz > > > Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following: > - a session is assigned (or created, if none existed before) > - its details are printed and the browser is told to refresh after 20 seconds > - before the browser refreshes, the session is invalidated server-side by separate thread. > Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors: > - The first stacktrace happens when the thread invalidates the session. > - The second stacktrace happens, when the browser refreshes. The user sees "Error 500". > - Then, after a minute or so, I get the last one. It then repeats periodically. > We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7225) Writing wrong realm-mapper to security-domain causes failures after reload

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-7225?page=com.atlassian.jira.plugin.... ] Ilia Vassilev commented on WFLY-7225: ------------------------------------- This issue is resolved with the PR [1] for https://issues.jboss.org/browse/WFLY-7224 [1] https://github.com/wildfly-security/elytron-subsystem/pull/244 > Writing wrong realm-mapper to security-domain causes failures after reload > -------------------------------------------------------------------------- > > Key: WFLY-7225 > URL: https://issues.jboss.org/browse/WFLY-7225 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > > In case when write-attribute operation to security-domain is used for some realm-mapper with pattern which does not include a capture group, then operation succeeded. However after server reload/restart exception occurs in server log and affected security domain does not start correctly. > Suggestion: > Writing wrong realm-mapper to security-domain should be denied. > Issue can be related to JBEAP-6214. > Exceptions in server log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group > at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64) > at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49) > at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > ... > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("security-domain" => "SomeSecurityDomain") > ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined} > 07:29:21,263 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("simple-regex-realm-mapper" => "SomeRealmMapper") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.realm-mapper.SomeRealmMapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: Failed to start service > Caused by: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.realm-mapper.SomeRealmMapper"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > ... > ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha8-redhat-2) started (with errors) in 616ms - Started 351 of 601 services (2 services failed or missing dependencies, 399 services are lazy, passive or on-demand) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7225) Writing wrong realm-mapper to security-domain causes failures after reload

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-7225?page=com.atlassian.jira.plugin.... ] Ilia Vassilev reassigned WFLY-7225: ----------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Writing wrong realm-mapper to security-domain causes failures after reload > -------------------------------------------------------------------------- > > Key: WFLY-7225 > URL: https://issues.jboss.org/browse/WFLY-7225 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > > In case when write-attribute operation to security-domain is used for some realm-mapper with pattern which does not include a capture group, then operation succeeded. However after server reload/restart exception occurs in server log and affected security domain does not start correctly. > Suggestion: > Writing wrong realm-mapper to security-domain should be denied. > Issue can be related to JBEAP-6214. > Exceptions in server log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group > at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64) > at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49) > at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > ... > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("security-domain" => "SomeSecurityDomain") > ]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined} > 07:29:21,263 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("simple-regex-realm-mapper" => "SomeRealmMapper") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.realm-mapper.SomeRealmMapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: Failed to start service > Caused by: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.realm-mapper.SomeRealmMapper"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > ... > ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP 7.1.0.Alpha1 (WildFly Core 3.0.0.Alpha8-redhat-2) started (with errors) in 616ms - Started 351 of 601 services (2 services failed or missing dependencies, 399 services are lazy, passive or on-demand) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-7229: ------------------------------------ [~micnowak1] I'm not sure why you need to disable server-side invalidation. There are two standard mechanisms for auto-invalidating sessions: # Per-session, via HttpSession.setMaxInactiveInterval(20 * 60); # Globally, via web.xml: {code:xml} <session-config> <session-timeout>20</session-timeout> </session-config> {code} > WFLYCLWEBUT0001 for server-side invalidated sessions > ---------------------------------------------------- > > Key: WFLY-7229 > URL: https://issues.jboss.org/browse/WFLY-7229 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes. > Reporter: Michał Nowakowski > Assignee: Paul Ferraro > Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz > > > Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following: > - a session is assigned (or created, if none existed before) > - its details are printed and the browser is told to refresh after 20 seconds > - before the browser refreshes, the session is invalidated server-side by separate thread. > Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors: > - The first stacktrace happens when the thread invalidates the session. > - The second stacktrace happens, when the browser refreshes. The user sees "Error 500". > - Then, after a minute or so, I get the last one. It then repeats periodically. > We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ] Paul Ferraro commented on WFCORE-1836: -------------------------------------- [~kabirkhan] Hmm - it might, but I doubt it. I'll try. If it works, I'll close this jira. > Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress > ---------------------------------------------------------------------------------------------------- > > Key: WFCORE-1836 > URL: https://issues.jboss.org/browse/WFCORE-1836 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Paul Ferraro > Assignee: Brian Stansberry > > For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails. > This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ] Lin Gao commented on WFCORE-1351: --------------------------------- I tried to use privileged action to create Endpoint using commit at: https://github.com/gaol/jboss-remote-naming/commit/340aebc46459b869f1c821... . The first 4 Permission check exceptions are gone, however, the last 2 permission check exceptions are still there: 1. new RuntimePermission("accessDeclaredMembers") -> [^5-no-suppressAccessChecks-permission.stracktrace] 2. new java.lang.reflect.ReflectPermission("suppressAccessChecks") -> Test Pass > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Critical > Fix For: 3.0.0.Alpha10 > > Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2105) Add support for SLF4J logger

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2105?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2105: -------------------------------- The preferred logger impl can be defined with system property "jgroups.log_class", e.g. {{-Djgroups.log_class=org.jgroups.logging.Slf4jLogImpl}}. > Add support for SLF4J logger > ---------------------------- > > Key: JGRP-2105 > URL: https://issues.jboss.org/browse/JGRP-2105 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Support sl4j logging -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7224) Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFLY-7224?page=com.atlassian.jira.plugin.... ] Ilia Vassilev reassigned WFLY-7224: ----------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Missing validation check for simple-regex-realm-mapper and mapped-regex-realm-mapper in Elytron subsystem > --------------------------------------------------------------------------------------------------------- > > Key: WFLY-7224 > URL: https://issues.jboss.org/browse/WFLY-7224 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > > Elytron subsystem allows to add realm mapper (e.g. simple-regex-realm-mapper) with pattern which does not include a capture group. In case when this realm mapper is used in add operation for security domain through CLI then operation fails with incomprehensible log: > {code} > { > "outcome" => "failed", > "failure-description" => {"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined}, > "rolled-back" => true > } > {code} > Exception in server log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.realm-mapper.SomeRealmMapper: org.jboss.msc.service.StartException in service org.wildfly.security.realm-mapper.SomeRealmMapper: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalArgumentException: ELY01065: Pattern requires a capture group > at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:64) > at org.wildfly.security.auth.util.SimpleRegexRealmMapper.<init>(SimpleRegexRealmMapper.java:49) > at org.wildfly.extension.elytron.RealmMapperDefinitions$SimpleRegexRealmMapperAddHandler.lambda$performRuntime$0(RealmMapperDefinitions.java:157) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... 3 more > {code} > The same happens for mapped-regex-realm-mapper. > Point here is that we allow to successfully add wrong realm mapper (without capture group) but we check whether it is wrong later in security domain. This check should be done during adding wrong realm mapper to avoid following incomprehensible CLI log and exception in server log. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider registration with Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1802: ------------------------------------- Description: We need to remove the following block from SecurityRealmResourceDefinition: - {code} static { //register the Openssl Provider, if possible //not really sure if this is the best place for it try { OpenSSLProvider.register(); DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); } catch (Throwable t){ DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); } } {code} Registration will then be possible within the Elytron subsystem configuration. > Integrate OpenSSL Provider registration with Elytron > ---------------------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha10 > > > We need to remove the following block from SecurityRealmResourceDefinition: - > {code} > static { > //register the Openssl Provider, if possible > //not really sure if this is the best place for it > try { > OpenSSLProvider.register(); > DomainManagementLogger.ROOT_LOGGER.registeredOpenSSLProvider(); > } catch (Throwable t){ > DomainManagementLogger.ROOT_LOGGER.debugf(t, "Failed to register OpenSSL provider"); > } > } > {code} > Registration will then be possible within the Elytron subsystem configuration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider registration with Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1802: ------------------------------------- Priority: Blocker (was: Major) > Integrate OpenSSL Provider registration with Elytron > ---------------------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider registration with Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-1802: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 > Integrate OpenSSL Provider registration with Elytron > ---------------------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1802) Integrate OpenSSL Provider registration with Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1802?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-1802: ---------------------------------------- Assignee: Darran Lofthouse > Integrate OpenSSL Provider registration with Elytron > ---------------------------------------------------- > > Key: WFCORE-1802 > URL: https://issues.jboss.org/browse/WFCORE-1802 > Project: WildFly Core > Issue Type: Task > Reporter: Stuart Douglas > Assignee: Darran Lofthouse > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1315) Expired fact with activationCount > 0 are not evicted from objectstore

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1315: ----------------------------------- Summary: Expired fact with activationCount > 0 are not evicted from objectstore Key: DROOLS-1315 URL: https://issues.jboss.org/browse/DROOLS-1315 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.5.0.CR2 Reporter: Matteo Mortari Assignee: Mario Fusco Fix For: 7.0.0.Final Expired fact with activationCount > 0 are not evicted from objectstore: intended behavior for serialization purposes, but for instance side-effects when used in an activation-group scenario where the rules are not 100% dual. Sized-down reproducer will be submitted at a later time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1310) Expired fact with activationCount > 0 are not evicted from objectstore

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1310?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1310: -------------------------------- Priority: Major (was: Minor) > Expired fact with activationCount > 0 are not evicted from objectstore > ---------------------------------------------------------------------- > > Key: DROOLS-1310 > URL: https://issues.jboss.org/browse/DROOLS-1310 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.CR2 > Reporter: Matteo Mortari > Assignee: Mario Fusco > Fix For: 7.0.0.Final > > Attachments: RuleTest.java > > > Expired fact with activationCount > 0 are not evicted from objectstore: intended behavior for serialization purposes, but for instance side-effects when used in an activation-group scenario where the rules are not 100% dual. > Sized-down reproducer will be submitted at a later time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7246) Upgrade to version 1.0.0.Alpha11 of the Elytron Subsystem

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-7246: -------------------------------------- Summary: Upgrade to version 1.0.0.Alpha11 of the Elytron Subsystem Key: WFLY-7246 URL: https://issues.jboss.org/browse/WFLY-7246 Project: WildFly Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7245) Upgrade to Artemis 1.4.0

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-7245: --------------------------------- Summary: Upgrade to Artemis 1.4.0 Key: WFLY-7245 URL: https://issues.jboss.org/browse/WFLY-7245 Project: WildFly Issue Type: Component Upgrade Components: JMS Reporter: Jeff Mesnil Assignee: Jeff Mesnil -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2105) Add support for SLF4J logger

by Bela Ban (JIRA)

Bela Ban created JGRP-2105: ------------------------------ Summary: Add support for SLF4J logger Key: JGRP-2105 URL: https://issues.jboss.org/browse/JGRP-2105 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0 Support sl4j logging -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2102) bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2102?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2102: -------------------------------- No, {{bind_interface}} is definitely not in 4.0: there's an attribute {{bind_interface}} in {{MPING}} and one in {{STATE_SOCK}}, but none in {{TP}}! > bind_interface="eth0" and bind_addr="LINK_LOCAL" config are conflict > -------------------------------------------------------------------- > > Key: JGRP-2102 > URL: https://issues.jboss.org/browse/JGRP-2102 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.6.1 > Environment: [root@wtc2k01v27 ~] CLONE # ip a > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > inet6 2606:ae00:e200:3f::83/128 scope global > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 > link/ether 00:50:56:ab:2a:ea brd ff:ff:ff:ff:ff:ff > inet 107.250.167.28/25 brd 107.250.167.127 scope global eth0 > inet6 2606:ae00:e200:3f::28/64 scope global > valid_lft forever preferred_lft forever > inet6 fe80::250:56ff:feab:2aea/64 scope link > valid_lft forever preferred_lft forever > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000 > link/ether 00:50:56:ab:d6:12 brd ff:ff:ff:ff:ff:ff > inet 192.168.0.59/24 brd 192.168.0.255 scope global eth1 > inet6 fe80::250:56ff:feab:d612/64 scope link > valid_lft forever preferred_lft forever > There're eth0 and eth1 exists in the environment > Reporter: 俐佳张 > Assignee: Bela Ban > Fix For: 3.6.12 > > Attachments: jgroups-udp.xml > > > Error happens while > Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000085: Error while trying to create a channel using the specified configuration file: /opt/oss/NSN-icf_notification_dispatcher/conf/jgroups-udp.xml > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:406) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:307) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:351) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:188) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:56) > at java.lang.reflect.Method.invoke(Method.java:620) > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869) > at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638) > at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627) > at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530) > at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:226) > ... 26 more > Caused by: java.lang.Exception: Property assignment of bind_interface in UDP with original property value eth0 and converted to null could not be assigned > at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1153) > at org.jgroups.stack.Configurator.createLayer(Configurator.java:444) > at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398) > at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90) > at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57) > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477) > at org.jgroups.JChannel.init(JChannel.java:854) > at org.jgroups.JChannel.<init>(JChannel.java:159) > at org.jgroups.JChannel.<init>(JChannel.java:129) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:404) > ... 39 more > Caused by: java.lang.Exception: Conversion of bind_interface in UDP with original property value eth0 failed > at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84) > at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1147) > ... 48 more > Caused by: java.lang.mail(a)example.comIllegalArgumentException: network interface eth0 does not contain address fe80:0:0:0:250:56ff:feab:d612%3 > at org.jgroups.util.Util.validateBindAddressFromInterface(Util.java:3132) > bind_interface="eth0" and bind_addr="LINK_LOCAL" config are config at the same time > but it couldn't get the eth0 link local address but return eth1 link local address > This code return the first address that match, it should return with eth0 > jgroups-3.6.1.Final-sources\org\jgroups\util\Util.java > public static InetAddress getAddress(AddressScope scope) ----> scope is LINK_LOCAL > throws SocketException > { > InetAddress address = null; > Enumeration intfs = NetworkInterface.getNetworkInterfaces(); > while (intfs.hasMoreElements()) { > NetworkInterface intf = (NetworkInterface)intfs.nextElement(); > try { > if (intf.isUp()) { > address = getAddress(intf, scope); -------> It will return the first LINK_LOCAL address from NICs list > if (address != null) > return address; > } > } > catch (SocketException e) { > } > } > return null; > } -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1842) Support RBAC based on raw roles from an Identity

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1842?page=com.atlassian.jira.plugi... ] Pedro Igor updated WFCORE-1842: ------------------------------- Component/s: Security > Support RBAC based on raw roles from an Identity > ------------------------------------------------- > > Key: WFCORE-1842 > URL: https://issues.jboss.org/browse/WFCORE-1842 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Pedro Igor > > Currently, RBAC requires a static mapping between standard roles and raw roles from an identity. > We should be able to use RBAC without necessarily forcing this static mapping and just consider the raw roles from the identity. > This issue may be related with exposing {{org.jboss.as.controller.access.management.WritableAuthorizerConfiguration#useRealmRoles}} in the management model. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1842) Support RBAC based on raw roles from an Identity

by Pedro Igor (JIRA)

Pedro Igor created WFCORE-1842: ---------------------------------- Summary: Support RBAC based on raw roles from an Identity Key: WFCORE-1842 URL: https://issues.jboss.org/browse/WFCORE-1842 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Pedro Igor Currently, RBAC requires a static mapping between standard roles and raw roles from an identity. We should be able to use RBAC without necessarily forcing this static mapping and just consider the raw roles from the identity. This issue may be related with exposing {{org.jboss.as.controller.access.management.WritableAuthorizerConfiguration#useRealmRoles}} in the management model. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3639) default-web-module doesn't work for non default hosts & servers

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-3639?page=com.atlassian.jira.plugin.... ] Kabir Khan reopened WFLY-3639: ------------------------------ > default-web-module doesn't work for non default hosts & servers > --------------------------------------------------------------- > > Key: WFLY-3639 > URL: https://issues.jboss.org/browse/WFLY-3639 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 11.0.0.Alpha1 > > > If you use config like this: > {code:xml} > <host name="default-host" default-web-module="myapp1.war" alias="webapp.domain1.com"/> > <host name="other-host" default-web-module="myapp2.war" alias="test.domain2.net"/> > {code} > and have apps myapp1.war & myapp2.war deployed myappwar2.war won't be bind to other-host. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3639) default-web-module doesn't work for non default hosts & servers

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-3639?page=com.atlassian.jira.plugin.... ] Kabir Khan commented on WFLY-3639: ---------------------------------- The fix in https://github.com/wildfly/wildfly/pull/9236 causes regressions https://ci.wildfly.org/viewLog.html?buildId=28148&tab=buildResultsDiv&bui... {code} org.jboss.as.test.integration.management.util.MgmtOperationException: Management operation failed: "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYUT0087: Duplicate default web module 'ROOT.war' configured on server 'default-server', host 'test'" at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67) at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37) at org.jboss.as.test.integration.management.base.AbstractMgmtTestBase.executeOperation(AbstractMgmtTestBase.java:73) at org.jboss.as.test.integration.management.base.AbstractMgmtTestBase.executeOperation(AbstractMgmtTestBase.java:85) at org.jboss.as.test.integration.management.api.web.VirtualServerTestCase.addVirtualServer(VirtualServerTestCase.java:139) at org.jboss.as.test.integration.management.api.web.VirtualServerTestCase.addRemoveVirtualServer(VirtualServerTestCase.java:100) ------- Stdout: ------- &amp#27;[0m02:01:58,958 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0028: Stopped deployment dummy.jar (runtime-name: dummy.jar) in 3ms &amp#27;[0m&amp#27;[0m02:01:58,966 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /opt/buildAgent/work/eef9fee5d4ca1630/testsuite/integration/basic/target/jbossas/standalone/data/content/2e/68ed26f1b74748fddd2839595a2c349cadbea7/content &amp#27;[0m&amp#27;[0m02:01:58,966 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "dummy.jar" (runtime-name: "dummy.jar") &amp#27;[0m02:01:58,971 INFO [org.jboss.as.test.integration.security.common.AbstractBaseSecurityRealmsServerSetupTask] (main) Removing security realm ssl-realm 02:01:58,992 INFO [org.jboss.as.test.integration.security.common.CoreUtils] (main) Client update: { "operation" => "remove", "address" => [ ("core-service" => "management"), ("security-realm" => "ssl-realm") ], "operation-headers" => { "rollback-on-runtime-failure" => false, "allow-resource-service-restart" => true } } 02:01:58,992 INFO [org.jboss.as.test.integration.security.common.CoreUtils] (main) Client update result: { "outcome" => "success", "response-headers" => {"process-state" => "reload-required"} } &amp#27;[0m02:01:59,029 INFO [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0001: Content added at location /opt/buildAgent/work/eef9fee5d4ca1630/testsuite/integration/basic/target/jbossas/standalone/data/content/98/aa708e24ea1eb7be904d2ac263ce54c84bc9e8/content &amp#27;[0m&amp#27;[0m02:01:59,032 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) WFLYSRV0027: Starting deployment of "dummy.jar" (runtime-name: "dummy.jar") &amp#27;[0m&amp#27;[33m02:01:59,039 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) WFLYSRV0018: Deployment "deployment.dummy.jar" is using a private module ("org.wildfly.security.manager:main") which may be changed or removed in future versions without notice. &amp#27;[0m&amp#27;[0m02:01:59,042 INFO [org.jboss.as.arquillian] (MSC service thread 1-4) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."dummy.jar",unit=dummy.jar,tests=[org.jboss.as.test.integration.management.api.web.VirtualServerTestCase]] &amp#27;[0m&amp#27;[0m02:01:59,050 INFO [org.jboss.as.server] (management-handler-thread - 4) WFLYSRV0010: Deployed "dummy.jar" (runtime-name : "dummy.jar") &amp#27;[0m&amp#27;[31m02:01:59,063 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "undertow"), ("server" => "default-server"), ("host" => "test") ]): java.lang.IllegalArgumentException: WFLYUT0087: Duplicate default web module 'ROOT.war' configured on server 'default-server', host 'test' at org.wildfly.extension.undertow.deployment.DefaultDeploymentMappingProvider.addMapping(DefaultDeploymentMappingProvider.java:59) at org.wildfly.extension.undertow.HostAdd.performRuntime(HostAdd.java:73) at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337) at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) &amp#27;[0m {code} > default-web-module doesn't work for non default hosts & servers > --------------------------------------------------------------- > > Key: WFLY-3639 > URL: https://issues.jboss.org/browse/WFLY-3639 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 11.0.0.Alpha1 > > > If you use config like this: > {code:xml} > <host name="default-host" default-web-module="myapp1.war" alias="webapp.domain1.com"/> > <host name="other-host" default-web-module="myapp2.war" alias="test.domain2.net"/> > {code} > and have apps myapp1.war & myapp2.war deployed myappwar2.war won't be bind to other-host. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1833) Fix ServiceLoader iterator issue

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1833?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFCORE-1833: ----------------------------------- Description: ServiceLoader regression in latest Jigsaw JDK9 builds is caused by fact ServiceLoader's iterator call to hasNext() method is not covered with ServiceConfigurationError try-catch statement. was: There's ServiceLoader regression in recent Jigsaw JDK9 builds. We will implement temporary workaround for this Jigsaw issue. This issue can be closed / resolved once this workaround will be eliminated from our code base. > Fix ServiceLoader iterator issue > -------------------------------- > > Key: WFCORE-1833 > URL: https://issues.jboss.org/browse/WFCORE-1833 > Project: WildFly Core > Issue Type: Sub-task > Reporter: Richard Opalka > Assignee: Richard Opalka > > ServiceLoader regression in latest Jigsaw JDK9 builds > is caused by fact ServiceLoader's iterator call to hasNext() method > is not covered with ServiceConfigurationError try-catch statement. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1833) Fix ServiceLoader iterator issue

by Richard Opalka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1833?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFCORE-1833: ----------------------------------- Summary: Fix ServiceLoader iterator issue (was: Temporarily workaround Jigsaw ServiceLoader regression) > Fix ServiceLoader iterator issue > -------------------------------- > > Key: WFCORE-1833 > URL: https://issues.jboss.org/browse/WFCORE-1833 > Project: WildFly Core > Issue Type: Sub-task > Reporter: Richard Opalka > Assignee: Richard Opalka > > There's ServiceLoader regression in recent Jigsaw JDK9 builds. > We will implement temporary workaround for this Jigsaw issue. > This issue can be closed / resolved once this workaround > will be eliminated from our code base. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1841) Subsystem parsers should be created lazily when needed

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1841?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-1841: ------------------------------------------ Something we did not mention when we talked about this but will also be benefit, there are scenarios where the version of the parser for the first load is different for all subsequent loads. > Subsystem parsers should be created lazily when needed > ------------------------------------------------------ > > Key: WFCORE-1841 > URL: https://issues.jboss.org/browse/WFCORE-1841 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > Currently when we register parsers for different versions of subsystem schema we always pass over instance of whole parser which is usually statically initialized. > In practice legacy (non current) parsers are only used rarely and there is no point in having them loaded in memory when not needed. > Impl should be based on provider pattern and as such also allow us to on demand create new instance of parser when needed, as well as enable us for parsers to be GCed, when they are not in use. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1841) Subsystem parsers should be created lazily when needed

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1841?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFCORE-1841: ----------------------------------- Summary: Subsystem parsers should be created lazily when needed (was: Subsystem parsers should be created lazly when need) > Subsystem parsers should be created lazily when needed > ------------------------------------------------------ > > Key: WFCORE-1841 > URL: https://issues.jboss.org/browse/WFCORE-1841 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > Currently when we register parsers for different versions of subsystem schema we always pass over instance of whole parser which is usually statically initialized. > In practice legacy (non current) parsers are only used rarely and there is no point in having them loaded in memory when not needed. > Impl should be based on provider pattern and as such also allow us to on demand create new instance of parser when needed, as well as enable us for parsers to be GCed, when they are not in use. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7209) Operation to list installed Resource Adapters

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-7209?page=com.atlassian.jira.plugin.... ] Stefano Maestri commented on WFLY-7209: --------------------------------------- You are confusing rar deployed (through deployment or modules) w/ activation (through subsystem or ironjacamar.xml) You could have more than one activation for each rar, and from a runtime POV activations are the only ones important. Frankly, I don't see an operation mixing both concepts as useful. > Operation to list installed Resource Adapters > --------------------------------------------- > > Key: WFLY-7209 > URL: https://issues.jboss.org/browse/WFLY-7209 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Reporter: Guillermo González de Agüero > Assignee: Stefano Maestri > Fix For: 10.1.0.Final > > > Currently there's no way to list all the installed Resource Adapters. Only configured resource adapters can be queried. However, they are automatically enabled at deployment time. > I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers. This would allow HAL to provide a wizard of available options when configuring them. > The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list() -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1841) Subsystem parsers should be created lazly when need

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-1841: ----------------------------------- Summary: Subsystem parsers should be created lazly when need Key: WFCORE-1841 URL: https://issues.jboss.org/browse/WFCORE-1841 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Tomaz Cerar Assignee: Tomaz Cerar Currently when we register parsers for different versions of subsystem schema we always pass over instance of whole parser which is usually statically initialized. In practice legacy (non current) parsers are only used rarely and there is no point in having them loaded in memory when not needed. Impl should be based on provider pattern and as such also allow us to on demand create new instance of parser when needed, as well as enable us for parsers to be GCed, when they are not in use. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7244) Web sockets are always enabled

by Kabir Khan (JIRA)

Kabir Khan created WFLY-7244: -------------------------------- Summary: Web sockets are always enabled Key: WFLY-7244 URL: https://issues.jboss.org/browse/WFLY-7244 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.1.0.Final Reporter: Kabir Khan Assignee: Stuart Douglas Fix For: 11.0.0.Alpha1 TCK testing for WFLY-6784 unearthed that websockets were always turned on in the undertow subsystem, while they should be explicitly turned on with the websocket element. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7243) Web sockets are always enabled

by Kabir Khan (JIRA)

Kabir Khan created WFLY-7243: -------------------------------- Summary: Web sockets are always enabled Key: WFLY-7243 URL: https://issues.jboss.org/browse/WFLY-7243 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.1.0.Final Reporter: Kabir Khan Assignee: Stuart Douglas Fix For: 11.0.0.Alpha1 TCK testing for WFLY-6784 unearthed that websockets were always turned on in the undertow subsystem, while they should be explicitly turned on with the websocket element. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1310) Expired fact with activationCount > 0 are not evicted from objectstore

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1310?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1310: ----------------------------------- Attachment: RuleTest.java Standalone JUnit reproducer for the case. > Expired fact with activationCount > 0 are not evicted from objectstore > ---------------------------------------------------------------------- > > Key: DROOLS-1310 > URL: https://issues.jboss.org/browse/DROOLS-1310 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.CR2 > Reporter: Matteo Mortari > Assignee: Mario Fusco > Priority: Minor > Attachments: RuleTest.java > > > Expired fact with activationCount > 0 are not evicted from objectstore: intended behavior for serialization purposes, but for instance side-effects when used in an activation-group scenario where the rules are not 100% dual. > Sized-down reproducer will be submitted at a later time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2217) Enable reload tests

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-2217?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski updated WFLY-2217: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9234 (was: https://github.com/wildfly/wildfly/pull/8437) > Enable reload tests > ------------------- > > Key: WFLY-2217 > URL: https://issues.jboss.org/browse/WFLY-2217 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 8.0.0.Beta1 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Original Estimate: 3 days > Time Spent: 4 days > Remaining Estimate: 0 minutes > > Tests need not stay ignored any longer! > Some tests which :reload are still ignored, even though :reload has been fixed ( well, it seems there is more to it due to other code changes ) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions

by Michał Nowakowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ] Michał Nowakowski commented on WFLY-7229: ----------------------------------------- @Paul: I'll try. We can disable server-side invalidation without losing security or functionality, but we're concerned about resources. Our interval has to be closer to 20 minutes than 20 seconds, and our sessions are not minute. Plus, no appserver we used before was having any problem with this invalidation, nor with being given valid cookies to invalid sessions - these were Tomcat, JBossAS and older versions of WF. I guess people that wrote CAS client for Java were also unaware of any. Or... is handling a HttpSession in context of a _foreign_ HttpRequest (that is, a request of a different session or with no session at all) still faithful to the spec? > WFLYCLWEBUT0001 for server-side invalidated sessions > ---------------------------------------------------- > > Key: WFLY-7229 > URL: https://issues.jboss.org/browse/WFLY-7229 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes. > Reporter: Michał Nowakowski > Assignee: Paul Ferraro > Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz > > > Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following: > - a session is assigned (or created, if none existed before) > - its details are printed and the browser is told to refresh after 20 seconds > - before the browser refreshes, the session is invalidated server-side by separate thread. > Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors: > - The first stacktrace happens when the thread invalidates the session. > - The second stacktrace happens, when the browser refreshes. The user sees "Error 500". > - Then, after a minute or so, I get the last one. It then repeats periodically. > We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2104) NAMING: provide logical names when IpAddressUUID is used as addresses

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2104?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2104. ---------------------------- Resolution: Done > NAMING: provide logical names when IpAddressUUID is used as addresses > --------------------------------------------------------------------- > > Key: JGRP-2104 > URL: https://issues.jboss.org/browse/JGRP-2104 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > This is a new protocol, typically added somewhere above {{NAKACK2}}. When {{TP.use_ip_addr}} is true, {{IpAddressUUID}} addresses will be used. > If {{Discovery.max_rank_to_reply}} is less than the max rank of the cluster view, not all members will receive discovery responses. They therefore won't have a mapping between the address and the logical name for all members. > {{NAMING}} fixes this by having the joiner multicast the address:name mapping after joining, and by everyone sending their mapping to the newly joined member as well. > Note that this protocol is not strictly necessary; as {{IpAddressUUID}} addresses will also work without logical names mapped to them, but it improves legibility, e.g. of logs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2104) NAMING: provide logical names when IpAddressUUID is used as addresses

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2104?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2104: --------------------------- Description: This is a new protocol, typically added somewhere above discovery (e.g. {{PING}}). When {{TP.use_ip_addr}} is true, {{IpAddressUUID}} addresses will be used. If {{Discovery.max_rank_to_reply}} is less than the max rank of the cluster view, not all members will receive discovery responses. They therefore won't have a mapping between the address and the logical name for all members. {{NAMING}} fixes this by having the joiner multicast the address:name mapping after joining, and by everyone sending their mapping to the newly joined member as well. Note that this protocol is not strictly necessary; as {{IpAddressUUID}} addresses will also work without logical names mapped to them, but it improves legibility, e.g. of logs. was: This is a new protocol, typically added somewhere above {{NAKACK2}}. When {{TP.use_ip_addr}} is true, {{IpAddressUUID}} addresses will be used. If {{Discovery.max_rank_to_reply}} is less than the max rank of the cluster view, not all members will receive discovery responses. They therefore won't have a mapping between the address and the logical name for all members. {{NAMING}} fixes this by having the joiner multicast the address:name mapping after joining, and by everyone sending their mapping to the newly joined member as well. Note that this protocol is not strictly necessary; as {{IpAddressUUID}} addresses will also work without logical names mapped to them, but it improves legibility, e.g. of logs. > NAMING: provide logical names when IpAddressUUID is used as addresses > --------------------------------------------------------------------- > > Key: JGRP-2104 > URL: https://issues.jboss.org/browse/JGRP-2104 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > This is a new protocol, typically added somewhere above discovery (e.g. {{PING}}). When {{TP.use_ip_addr}} is true, {{IpAddressUUID}} addresses will be used. > If {{Discovery.max_rank_to_reply}} is less than the max rank of the cluster view, not all members will receive discovery responses. They therefore won't have a mapping between the address and the logical name for all members. > {{NAMING}} fixes this by having the joiner multicast the address:name mapping after joining, and by everyone sending their mapping to the newly joined member as well. > Note that this protocol is not strictly necessary; as {{IpAddressUUID}} addresses will also work without logical names mapped to them, but it improves legibility, e.g. of logs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7193) No log messages comming from Elytron - ssl context creation

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7193?page=com.atlassian.jira.plugin.... ] Jan Kalina reassigned WFLY-7193: -------------------------------- Assignee: Jan Kalina > No log messages comming from Elytron - ssl context creation > ----------------------------------------------------------- > > Key: WFLY-7193 > URL: https://issues.jboss.org/browse/WFLY-7193 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > > Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details. > Seems to me it would be useful for troubleshooting to have logged on TRACE level: > - Keystore initialization with parameters > - Filtering keystore initialization with parameters > - KeyManager / TrustManager initialization with parameters > - Client / Server SSLContext initialization with parameters -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ] Martin Choma commented on ELY-627: ---------------------------------- Also note, there should be possible to configure protocols like "openssl.TLS" introduced by https://issues.jboss.org/browse/WFCORE-1757. > Elytron introduces SSL/TLS protocol constraints > ----------------------------------------------- > > Key: ELY-627 > URL: https://issues.jboss.org/browse/ELY-627 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.1.0.Beta8 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > > {noformat} > "protocols" => { > "type" => LIST, > "description" => "The enabled protocols.", > "expressions-allowed" => true, > "nillable" => false, > "allowed" => [ > "SSLv2", > "SSLv3", > "TLSv1", > "TLSv1_1", > "TLSv1_2", > "TLSv1_3" > ], > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {noformat} > Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values? > Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value. > IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java. > Note, IBM java already today defines little bit different protocols set [2] > I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place. > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN... > [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-673) Elytron Integration with Core

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-673?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-673: ------------------------------------ Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Elytron Integration with Core > ----------------------------- > > Key: WFCORE-673 > URL: https://issues.jboss.org/browse/WFCORE-673 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha10 > > > This is the top level tracking task for Elytron integration within core. The tasks for the changes actually being made will either be linked or added as sub-tasks. > In addition to this general issues that affect the Elytron integration are being labelled with 'affects_elytron' and can be queried using the following query: - > https://issues.jboss.org/issues/?filter=12323574 > The label is a general catch-all for issues that are of interest to us but are not automatically blockers for our progress. > The general criteria for the resolution of this issue will be: - > - Inclusion of the Elytron Subsystem in core > - All network entry points in core to be securable using Elytron > - All SSL artefacts to be obtainable from Elytron. > Note: The legacy modes will become better defined as we progress but whilst it must be possible to use Elytron it's use may still be optional to a certain degree. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-610) Integrate Elytron for management security.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-610?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-610: ------------------------------------ Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Integrate Elytron for management security. > ------------------------------------------ > > Key: WFCORE-610 > URL: https://issues.jboss.org/browse/WFCORE-610 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha10 > > > This is a top level container task for the integration of Elytron for domain management security. > Do note however that the purpose of Elytron is a single unified security solution across the whole of the application server so many tasks here will be groundwork for the remainder of the integration. > At the moment the Elytron subsystem is being developed outside of wildfly-core, this will need to change in the future due to dependency issues (i.e. to write a subsystem you need to depend on core and core will need to include the subsystem (I think.)). However this will make it easier for now to ensure that the subsystem is 100% with no WildFly code accessing the subsystem - and also verify that we can create a distribtion with out the subsystem and still have a functional server. > Overall if someone came up with an alternative subsystem that provided the same capabilities it should be possible to drop it in. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-363: ------------------------------------ Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > ManagementResourceRegistration.getOverrideModel never returns null > ------------------------------------------------------------------ > > Key: WFCORE-363 > URL: https://issues.jboss.org/browse/WFCORE-363 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Alpha10 > > > ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct. > The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should. > This bug is the cause of the initial failure of my WFLY-2880 fix. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-311) Better error message if authentication is required to connect to the master but no realm is associated on the slave

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-311?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-311: ------------------------------------ Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Better error message if authentication is required to connect to the master but no realm is associated on the slave > ------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-311 > URL: https://issues.jboss.org/browse/WFCORE-311 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Environment: RH EL 6.3 - JBoss EAP 6.2 > Reporter: Riccardo Benvenuti > Assignee: Brian Stansberry > Priority: Minor > Fix For: 3.0.0.Alpha10 > > > In JBoss 6.2 domain environment if in the host.xml file on the slave is missing the realm in the domain-controller tag as reported below > <domain-controller> > <remote host="10.123.137.200" port="9999"/> > </domain-controller> > we get the following error: > JBoss Bootstrap Environment > JBOSS_HOME: /opt/jboss7/jboss-eap-6.2 > JAVA: /usr/java/jdk1.7.0_51/bin/java > JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true > ========================================================================= > 16:45:58,529 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2 > 16:45:58,746 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller' > [Host Controller] 16:45:59,735 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2 > [Host Controller] 16:45:59,913 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA-redhat-1 > [Host Controller] 16:46:00,023 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) starting > [Host Controller] 16:46:00,991 INFO [org.xnio] (MSC service thread 1-1) XNIO Version 3.0.7.GA-redhat-1 > [Host Controller] 16:46:01,010 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.0.7.GA-redhat-1 > [Host Controller] 16:46:01,033 INFO [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (management) port (9990) securePort (-1) > [Host Controller] 16:46:01,045 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 3.2.18.GA-redhat-1 > [Host Controller] 16:46:01,173 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 10.123.137.201:9999 > [Host Controller] 16:46:01,857 ERROR [org.jboss.remoting.remote.connection] (Remoting "testjb7s1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed > [Host Controller] 16:46:01,869 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS010942: Unable to connect due to authentication failure. > [Host Controller] 16:46:01,891 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report > [Host Controller] JBAS014775: New missing/unsatisfied dependencies: > [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (missing) dependents: [service jboss.server.controller.management.security_realm.ApplicationRealm] > [Host Controller] > [Host Controller] 16:46:01,897 INFO [org.jboss.as.controller] (MSC service thread 1-1) JBAS014774: Service status report > [Host Controller] JBAS014775: New missing/unsatisfied dependencies: > [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (missing) dependents: [service jboss.remoting.authentication_provider.management] > [Host Controller] > [Host Controller] 16:46:01,922 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report > [Host Controller] JBAS014776: Newly corrected services: > [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (no longer required) > [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (no longer required) > [Host Controller] > [Host Controller] 16:46:01,927 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) stopped in 28ms > 16:46:02,245 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 99 > 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012016: Shutting down process controller > 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012015: All processes finished; exiting > Adding the realm everything works correctly > <domain-controller> > <remote host="10.123.137.200" port="9999" security-realm="ManagementRealm"/> > </domain-controller> > Maybe a warning message could be useful to find the problem. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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 Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-296?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-296: ------------------------------------ Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > 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: Darran Lofthouse > 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFCORE-13: ----------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Labels: EAP > Fix For: 3.0.0.Alpha10 > > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1282: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string > --------------------------------------------------------------------------------------- > > Key: WFCORE-1282 > URL: https://issues.jboss.org/browse/WFCORE-1282 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 1.0.2.Final > Environment: Oracle Java > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Alpha10 > > Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log > > > User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7. > Setting as critical as these cipher suites, are considered for strong and widely used in my opinion. > In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all. > Note, that analogous configuration in EAP6 works fine. > Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites(). > Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1157) Managmement and JMX notifications when ControlledProcessState changes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1157?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1157: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Managmement and JMX notifications when ControlledProcessState changes > --------------------------------------------------------------------- > > Key: WFCORE-1157 > URL: https://issues.jboss.org/browse/WFCORE-1157 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, JMX > Reporter: Brian Stansberry > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha10 > > > When Jeff Mesnil added the core management notification stuff an obvious thing to do was to emit notifications around ControlledProcessState changes. But I forgot. :( So lets do it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1145: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Review of HostController / Application Server Remoting connections > ------------------------------------------------------------------ > > Key: WFCORE-1145 > URL: https://issues.jboss.org/browse/WFCORE-1145 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Alpha10 > > > Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access. > The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1059) RestartParentResourceAdd/RemoveHandler should handle capability registration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1059?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1059: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > RestartParentResourceAdd/RemoveHandler should handle capability registration > ---------------------------------------------------------------------------- > > Key: WFCORE-1059 > URL: https://issues.jboss.org/browse/WFCORE-1059 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha10 > > > RestartParentResourceAddHandler and RestartParentResourceRemoveHandler do not extend the respective AbstractAddStepHandler and AbstractRemoveStepHandler base classes, and thus does not handle capability [un]registration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1006) Upgrade to PicketBox 5

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1006?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1006: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Upgrade to PicketBox 5 > ---------------------- > > Key: WFCORE-1006 > URL: https://issues.jboss.org/browse/WFCORE-1006 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Stefan Guilhen > Fix For: 3.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1438) Elytron integration with logging subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1438?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1438: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Elytron integration with logging subsystem > ------------------------------------------ > > Key: WFCORE-1438 > URL: https://issues.jboss.org/browse/WFCORE-1438 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha10 > > > This is primarily an investigation task to start with, Logging can use syslog, Syslog access can be protected with TLS, Elytron is providing unified SSL configuration - do we need to bring these together. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1400) Update management interfaces to obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1400?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1400: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Update management interfaces to obtain the SSLContext using the new 'org.wildfly.security.ssl-context' capability > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1400 > URL: https://issues.jboss.org/browse/WFCORE-1400 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1351) FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1351?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1351: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > FilePermission for XNIO and Marshalling modules are required for Remoting to run with security manager > ------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1351 > URL: https://issues.jboss.org/browse/WFCORE-1351 > Project: WildFly Core > Issue Type: Bug > Components: Remoting, Security > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Critical > Fix For: 3.0.0.Alpha10 > > Attachments: 1-no-createEndpoint-permission.stacktrace, 2-no-createXnioWorker-permission.stacktrace, 3-no-addConnectionProvider-permission.stacktrace, 4-no-accessDeclaredMembers-permission.stractrace, 5-no-suppressAccessChecks-permission.stracktrace > > > # Running _NestedRemoteContextTestCase_ (from WildFly _testsuite/integration/basic_) with security manager, like > {noformat} > ./integration-tests.sh -Dts.basic -Dts.noSmoke -Dtest=NestedRemoteContextTestCase -Dsecurity.manager > {noformat} > results in exception: > {noformat} > java.io.IOException: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found > {noformat} > To make it work, permissions like following need to be added to _permissions.xml_ of _ejb.ear_: > {noformat} > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/xnio/nio/main/*", "read"), > new FilePermission("/home/okotek/git/wildfly/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/jboss/marshalling/river/main/*", "read"), > new RemotingPermission("createEndpoint"), > new RuntimePermission("createXnioWorker"), > new RemotingPermission("addConnectionProvider"), > new RuntimePermission("modifyThread"), > new RuntimePermission("accessDeclaredMembers"), > new ReflectPermission("suppressAccessChecks") > {noformat} > which is very confusing. > Why do I need add seemingly unrelated permissions, like _FilePermission_ for XNIO and marshalling or _RuntimePermission_ for createXnioWorker? Such behavior should be fixed or properly documented. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1602) Elytron integration with JMX

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1602?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1602: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Elytron integration with JMX > ---------------------------- > > Key: WFCORE-1602 > URL: https://issues.jboss.org/browse/WFCORE-1602 > Project: WildFly Core > Issue Type: Feature Request > Components: JMX > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1600) Update the legacy security realms to add factory methods to obtain SaslAuthenticationFactory and HttpAuthenticationFactory instances.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1600?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1600: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Update the legacy security realms to add factory methods to obtain SaslAuthenticationFactory and HttpAuthenticationFactory instances. > ------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1600 > URL: https://issues.jboss.org/browse/WFCORE-1600 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha10 > > > These are for use when security realms are directly referenced, although Elytron types these should not be advertised as capabilities as these are for specific backwards compatibility requirements and not to increase their use as Elytron capabilities. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1598) Conversion of Elytron SecurityIdentity to Subject for communication with older hosts.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1598?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1598: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Conversion of Elytron SecurityIdentity to Subject for communication with older hosts. > ------------------------------------------------------------------------------------- > > Key: WFCORE-1598 > URL: https://issues.jboss.org/browse/WFCORE-1598 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha10 > > > In the domain hierarchy clients trust the server they communicate with so this server currently sends a serialized representation of the Subject containing information about the user initiating the request. > For Elytron we will use the new identity propagation features however for older slaves we will need to convert to a Subject representation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1533) Integrate Management Access Control permission assignment with Elytron

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1533?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1533: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Integrate Management Access Control permission assignment with Elytron > ---------------------------------------------------------------------- > > Key: WFCORE-1533 > URL: https://issues.jboss.org/browse/WFCORE-1533 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 3.0.0.Alpha10 > > > A big portion of management role based access control is taking the assigned roles and then mapping these to the permissions for that role. > Elytron provides a new PermissionMapper interface that takes a SecurityIdentity and the roles mapped for that identity and returns a PermissionVerifier which can be as simple as a wrapper around a PermissionCollection. > This will also be a good opportunity to start to move the role mapping out of the core management model to Elytron. > After that Elytron allows for custom PermissionMapper implementations to be provided and associated with the domain using capabilities and requirements so we arrive at a point where provided the permission checks performed by management are generic enough custom PermissionMapper / PermissionVerifier implementations can be added that may or may not be role based. > _Note: As with everything we are doing old and new need to be supported in parallel for a while although this may be achieved by providing default Elytron implementations that are wrappers around the old._ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1834) Unexpected attribute error message doesn't list 'name' attribute.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1834?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1834: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Unexpected attribute error message doesn't list 'name' attribute. > ----------------------------------------------------------------- > > Key: WFCORE-1834 > URL: https://issues.jboss.org/browse/WFCORE-1834 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha10 > > > I have recently updated one of our resource definitions and missed updating one of the subsystem templates so currently have the following error reported: - > {noformat} > Message: WFLYCTL0376: Unexpected attribute 'security-domain' encountered. Valid attributes are: 'http-authentication-factory, override-deployment-config' > [Host Controller] at org.jboss.as.controller.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:128) > {noformat} > Previously my resource has been using the 'security-domain' attribute for it's name but now has been reverted to using 'name' for the name - in the above error message 'name' should have been listed as one of the valid attributes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1822) Address thread safety of CredentialReference

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1822?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1822: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Address thread safety of CredentialReference > -------------------------------------------- > > Key: WFCORE-1822 > URL: https://issues.jboss.org/browse/WFCORE-1822 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Fix For: 3.0.0.Alpha10 > > > Following on from the comments in this pull requests some minor follow up is required regarding thread safety of CredentialReference: - > https://github.com/wildfly/wildfly-core/pull/1816 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1805) Intermittent failure in BasicOperationsUnitTestCase.testPathInfo

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1805?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1805: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Intermittent failure in BasicOperationsUnitTestCase.testPathInfo > ---------------------------------------------------------------- > > Key: WFCORE-1805 > URL: https://issues.jboss.org/browse/WFCORE-1805 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Affects Versions: 3.0.0.Alpha7 > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Alpha10 > > > This test is failing intermittently. I'm going to @Ignore it. > This one should be a bit higher priority than the typical intermittent test failure as the stuff being tested is pretty new, so there's a higher chance this is a bug in the code instead of just a test issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1701) In-VM Identity Representation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1701?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1701: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > In-VM Identity Representation > ----------------------------- > > Key: WFCORE-1701 > URL: https://issues.jboss.org/browse/WFCORE-1701 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha10 > > > If Elytron has no current SecurityIdentity then an anonymous identity is used. The issue however is that this anonymous identity could be because the current user does not have access to be inflowed to the SecurityDomain being used for management or it could be because it is an in-vm call and no identity is established. > We need a solution to safely represent an in-vm call and differentiate it from a user with no appropriate identity, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1694) Upgrade to WildFly Client Config 1.0.0.Beta1

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1694?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1694: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Upgrade to WildFly Client Config 1.0.0.Beta1 > -------------------------------------------- > > Key: WFCORE-1694 > URL: https://issues.jboss.org/browse/WFCORE-1694 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1693) Upgrade to JBoss Remoting 5.0.0.Beta4

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1693?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1693: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Upgrade to JBoss Remoting 5.0.0.Beta4 > ------------------------------------- > > Key: WFCORE-1693 > URL: https://issues.jboss.org/browse/WFCORE-1693 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1691) Upgrade to Remoting JMX 3.0.0.Alpha1

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1691?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1691: ------------------------------------- Fix Version/s: 3.0.0.Alpha10 (was: 3.0.0.Alpha9) > Upgrade to Remoting JMX 3.0.0.Alpha1 > ------------------------------------ > > Key: WFCORE-1691 > URL: https://issues.jboss.org/browse/WFCORE-1691 > Project: WildFly Core > Issue Type: Component Upgrade > Components: JMX > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1805) Intermittent failure in BasicOperationsUnitTestCase.testPathInfo

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1805?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1805: ------------------------------------------ The PR is merged for Alpha9 but I'll leave this open until https://github.com/wildfly/wildfly-core/pull/1837 is in as well as that further hardens the test. > Intermittent failure in BasicOperationsUnitTestCase.testPathInfo > ---------------------------------------------------------------- > > Key: WFCORE-1805 > URL: https://issues.jboss.org/browse/WFCORE-1805 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Affects Versions: 3.0.0.Alpha7 > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Alpha9 > > > This test is failing intermittently. I'm going to @Ignore it. > This one should be a bit higher priority than the typical intermittent test failure as the stuff being tested is pretty new, so there's a higher chance this is a bug in the code instead of just a test issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6784) Add possibility to enable websocket compression via management model

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6784?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-6784: -------------------------------------- The PR was actually correct. Unfortunately the PR fixed a bug (websockets would always be enabled even if there is no websocket element) and that uncovered a problem with the TCK config (namely that websockets are not enabled). > Add possibility to enable websocket compression via management model > -------------------------------------------------------------------- > > Key: WFLY-6784 > URL: https://issues.jboss.org/browse/WFLY-6784 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Radim Hatlapatka > Assignee: Ingo Weiss > Priority: Critical > Labels: downstream_dependency > Fix For: 11.0.0.Alpha1 > > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > In EAP 6 the websockets compression was enabled by default allowing to use pre-deflate compression when requested by client. > There is support for it in Undertow but there is no option to enable it in WildFly 10. This option should be added to WildFly and should probably set by default to true as that would be consistent with default behaviour when using WebSockets with EAP 6.4. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-646) Unable to setup CLIENT_CERT authentication with elytron.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-646?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-646: -------------------------------- Note: Pull request in header is sufficient to fix the problem, but to have green subsystem tests, following subsystem pull request is need: https://github.com/wildfly-security/elytron-subsystem/pull/240 (Changed exception, which is thrown when client-auth was not provided.) > Unable to setup CLIENT_CERT authentication with elytron. > -------------------------------------------------------- > > Key: ELY-646 > URL: https://issues.jboss.org/browse/ELY-646 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > Following Zach's notes on [How to setup 2 way TLS|https://gitlab.cee.redhat.com/zrhoads/kbase/blob/master/eap71.elytron...] I am unable to setup it properly. User is not requested by browser for specifying client certificate and get access to application without certificate. > In log you there is: > 1. Server send request for certificate > {code} > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) *** CertificateRequest > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Types: RSA, DSS, ECDSA > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Authorities: > ^[[0m^[[0m13:55:33,310 INFO [stdout] (default task-1) <CN=client> > {code} > 2. And client responds with empty certificate chain. Without asking for certificate > {code} > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) *** Certificate chain > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) <Empty> > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) *** > {code} > I am attaching: > * server.log - server log with -Djavax.net.debug=all turn on. > * 2wayTLS.pcap - wireshark recording of port 8443 > * secured-app - tested application -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7240) CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7240?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7240: --------------------------------- Fix Version/s: 11.0.0.Alpha1 > CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split > ----------------------------------------------------------------------------------------------- > > Key: WFLY-7240 > URL: https://issues.jboss.org/browse/WFLY-7240 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > One of the manifestation of the issue: > # start 2 nodes with SLSB with TUNNEL transport > # start both nodes creating 2 clusters (or partitions) > # start ejb client > # start GossipRouter and wait for merge > # ejb client keeps talking only to known node; never receives a topology update > This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges and thus all entries from a given partition will be lost forever. > The effects are especially missing client mappings and broken session stickiness. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7240) CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7240?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7240: --------------------------------- Description: One of the manifestation of the issue: # start 2 nodes with SLSB with TUNNEL transport # start both nodes creating 2 clusters (or partitions) # start ejb client # start GossipRouter and wait for merge # ejb client keeps talking only to known node; never receives a topology update This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges and thus all entries from a given partition will be lost forever. The effects are especially missing client mappings and broken session stickiness. was: One of the manifestation of the issue: # start 2 nodes with SLSB with TUNNEL transport # start both nodes creating 2 clusters (or partitions) # start ejb client # start GossipRouter and wait for merge # ejb client keeps talking only to known node; never receives a topology update This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges. > CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split > ----------------------------------------------------------------------------------------------- > > Key: WFLY-7240 > URL: https://issues.jboss.org/browse/WFLY-7240 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > One of the manifestation of the issue: > # start 2 nodes with SLSB with TUNNEL transport > # start both nodes creating 2 clusters (or partitions) > # start ejb client > # start GossipRouter and wait for merge > # ejb client keeps talking only to known node; never receives a topology update > This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges and thus all entries from a given partition will be lost forever. > The effects are especially missing client mappings and broken session stickiness. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7242) CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-7242: ------------------------------------ Summary: CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split Key: WFLY-7242 URL: https://issues.jboss.org/browse/WFLY-7242 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.Final, 10.1.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Priority: Critical Fix For: 11.0.0.Alpha1 One of the manifestation of the issue: # start 2 nodes with SLSB with TUNNEL transport # start both nodes creating 2 clusters (or partitions) # start ejb client # start GossipRouter and wait for merge # ejb client keeps talking only to known node; never receives a topology update This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges and thus all entries from a given partition will be lost forever. The effects are especially missing client mappings and broken session stickiness. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management

by Bill Tuminaro (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ] Bill Tuminaro updated DROOLS-1313: ---------------------------------- Attachment: SimpleTest2_dump2.PNG SimpleTest2_dump1.PNG SimpleTest2_dump3.PNG SAVE_SimpleTest2.java > Memory Leak - but is this a supported scenario for Dynamic rule management > -------------------------------------------------------------------------- > > Key: DROOLS-1313 > URL: https://issues.jboss.org/browse/DROOLS-1313 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Bill Tuminaro > Assignee: Mario Fusco > Attachments: SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG > > > I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/). > However, I am not sure this is a supported scenario. If this is a supported approach this needs to get fixed, otherwise we need to use another approach. > The attached source does this: > +*Initialize stuff*+ > - Create a new ReleaseId > - Create a new KieFileSystem > - Generate and write the PomXML for the ReleaseId created above > - Create a new KieModuleModel > - Create a new KieBaseModel > - Write the ModuleModel XML to the KieFileSystem > - Write 2 rules into the KieFileSystem > +*1st build and dump*+ > - Create a new KieBuilder > - Do a buildall() with the KieBuilder > - Create a new KieContainer > - Create a new KieSession from the KieContainer > - Print out the rules in the KieContainer for the package used in my rules > - Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected. > +*2nd build and dump*+ > - Delete 2 rules from the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Add 2 new rules to the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Print out the rules in the KieContainer for the package used in my rules > - Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png. > - Rule_120_Triggered_Part_1_ 0 is not there > - Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak) > +*3rd build and dump*+ > - Delete 1 rule from the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Add 2 new rules to the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Print out the rules in the KieContainer for the package used in my rules > - Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png. > - Rule_120_Triggered_Part_1_ 0 is STILL not there > - TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak) > - Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management

by Bill Tuminaro (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ] Bill Tuminaro commented on DROOLS-1313: --------------------------------------- I wrote another reproducer (SAVE_SimpleTest2.java) that uses the approach outlined in the org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest.java code. I am really confused now, this approach seems to generate even more classloaders, classes and instances. Can you shed some light on what the correct way to dynamically modify the rules in a module AND not keep consuming memory/heap space? I have attached the code and 3 MAT screenshots. -BillT > Memory Leak - but is this a supported scenario for Dynamic rule management > -------------------------------------------------------------------------- > > Key: DROOLS-1313 > URL: https://issues.jboss.org/browse/DROOLS-1313 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Bill Tuminaro > Assignee: Mario Fusco > Attachments: SAVE_SimpleTest.java, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG > > > I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/). > However, I am not sure this is a supported scenario. If this is a supported approach this needs to get fixed, otherwise we need to use another approach. > The attached source does this: > +*Initialize stuff*+ > - Create a new ReleaseId > - Create a new KieFileSystem > - Generate and write the PomXML for the ReleaseId created above > - Create a new KieModuleModel > - Create a new KieBaseModel > - Write the ModuleModel XML to the KieFileSystem > - Write 2 rules into the KieFileSystem > +*1st build and dump*+ > - Create a new KieBuilder > - Do a buildall() with the KieBuilder > - Create a new KieContainer > - Create a new KieSession from the KieContainer > - Print out the rules in the KieContainer for the package used in my rules > - Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected. > +*2nd build and dump*+ > - Delete 2 rules from the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Add 2 new rules to the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Print out the rules in the KieContainer for the package used in my rules > - Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png. > - Rule_120_Triggered_Part_1_ 0 is not there > - Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak) > +*3rd build and dump*+ > - Delete 1 rule from the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Add 2 new rules to the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Print out the rules in the KieContainer for the package used in my rules > - Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png. > - Rule_120_Triggered_Part_1_ 0 is STILL not there > - TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak) > - Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1314) Compilation of spreadsheet fails with specific condition

by Alessandro Lazarotti (JIRA)

Alessandro Lazarotti created DROOLS-1314: -------------------------------------------- Summary: Compilation of spreadsheet fails with specific condition Key: DROOLS-1314 URL: https://issues.jboss.org/browse/DROOLS-1314 Project: Drools Issue Type: Bug Components: build, decision tables Affects Versions: 6.4.0.Final Reporter: Alessandro Lazarotti Assignee: Michael Anstis Priority: Critical Fix For: 6.5.0.Final Reproducer is attached.with problematic spredsheet named SampleNG.xml. Compilation of this fails with the following error. java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=dtables/SampleNG.xls, line=8, column=0 text=Unable to Analyse Expression checktest == AAA: [Error: unable to resolve method using strict-mode: com.sample.DecisionTableTest$Message.AAA()] [Near : {... checktest == AAA ....}] because the following DRL is generated. rule "HelloWorld_12" when m:Message(checktest in (AAA), status == "Message.HELLO") ... i.e. double quotation of value ("AAA") specified in the cell is removed. If D column does not exist like Sample.xml(also included in reproducer) or rule template of D column is modified like "status == $param " (see SampleOK.xml), this does not happen. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1760) Extension initialization handling makes use of PersistentResourceDefinition overly difficult

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1760?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFCORE-1760. -------------------------------------- Fix Version/s: 3.0.0.Alpha9 Assignee: Tomaz Cerar Resolution: Done Tomaz solved this problem in a much much much simpler way with WFCORE-1831. :) > Extension initialization handling makes use of PersistentResourceDefinition overly difficult > -------------------------------------------------------------------------------------------- > > Key: WFCORE-1760 > URL: https://issues.jboss.org/browse/WFCORE-1760 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 3.0.0.Alpha9 > > > PersistentResourceXMLBuilder.build() requires a PersistentResourceDefinition as an input. This is a problem because the PersistentResourcXmlDefinition is needed to initialize parsers for Extension.initializeParsers(), which is called *before* Extension.initialize(). And Extension.initialize() is when the PersistentResourceDefinition would normally be constructed. > An Extension implementation could overcome this by maintaining internal state. Construct the PersistentResourceDefinition in initializeParsers() and store it in an instance field for use in initialize(). Or vice versa. That gets messy though as now the Extension impl is needing to worry about the order in which the two methods are called and tracking whether both have been called so it can drop the cached object. > A possible thing to do is the have the ExtensionContext and ExtensionParsingContext offer an attachment API, with the lifecycle of attachments documented as being scoped to a single overall extension initialization. That could work but isn't very elegant. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6784) Add possibility to enable websocket compression via management model

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-6784?page=com.atlassian.jira.plugin.... ] Kabir Khan commented on WFLY-6784: ---------------------------------- [~swd847] [~iweiss] The PR has been reverted since it caused TCK failures. [~smarlow] can provide more details. > Add possibility to enable websocket compression via management model > -------------------------------------------------------------------- > > Key: WFLY-6784 > URL: https://issues.jboss.org/browse/WFLY-6784 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Radim Hatlapatka > Assignee: Ingo Weiss > Priority: Critical > Labels: downstream_dependency > Fix For: 11.0.0.Alpha1 > > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > In EAP 6 the websockets compression was enabled by default allowing to use pre-deflate compression when requested by client. > There is support for it in Undertow but there is no option to enable it in WildFly 10. This option should be added to WildFly and should probably set by default to true as that would be consistent with default behaviour when using WebSockets with EAP 6.4. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6784) Add possibility to enable websocket compression via management model

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-6784?page=com.atlassian.jira.plugin.... ] Kabir Khan reopened WFLY-6784: ------------------------------ > Add possibility to enable websocket compression via management model > -------------------------------------------------------------------- > > Key: WFLY-6784 > URL: https://issues.jboss.org/browse/WFLY-6784 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Radim Hatlapatka > Assignee: Ingo Weiss > Priority: Critical > Labels: downstream_dependency > Fix For: 11.0.0.Alpha1 > > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > In EAP 6 the websockets compression was enabled by default allowing to use pre-deflate compression when requested by client. > There is support for it in Undertow but there is no option to enable it in WildFly 10. This option should be added to WildFly and should probably set by default to true as that would be consistent with default behaviour when using WebSockets with EAP 6.4. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management

by Bill Tuminaro (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ] Bill Tuminaro commented on DROOLS-1313: --------------------------------------- I forgot to mention, we have thousands of rules, we use the approach outlined above to try to avoid rewriting the entire kfs when rules change. When a rule changes, we simply delete the old file and add a new one with a new name into the existing KieFileSystem. -BillT > Memory Leak - but is this a supported scenario for Dynamic rule management > -------------------------------------------------------------------------- > > Key: DROOLS-1313 > URL: https://issues.jboss.org/browse/DROOLS-1313 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Bill Tuminaro > Assignee: Mario Fusco > Attachments: SAVE_SimpleTest.java, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG > > > I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/). > However, I am not sure this is a supported scenario. If this is a supported approach this needs to get fixed, otherwise we need to use another approach. > The attached source does this: > +*Initialize stuff*+ > - Create a new ReleaseId > - Create a new KieFileSystem > - Generate and write the PomXML for the ReleaseId created above > - Create a new KieModuleModel > - Create a new KieBaseModel > - Write the ModuleModel XML to the KieFileSystem > - Write 2 rules into the KieFileSystem > +*1st build and dump*+ > - Create a new KieBuilder > - Do a buildall() with the KieBuilder > - Create a new KieContainer > - Create a new KieSession from the KieContainer > - Print out the rules in the KieContainer for the package used in my rules > - Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected. > +*2nd build and dump*+ > - Delete 2 rules from the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Add 2 new rules to the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Print out the rules in the KieContainer for the package used in my rules > - Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png. > - Rule_120_Triggered_Part_1_ 0 is not there > - Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak) > +*3rd build and dump*+ > - Delete 1 rule from the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Add 2 new rules to the KieFileSystem created above > - Call incrementalBuild() on the KieBuilder created above > - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above > - Print out the rules in the KieContainer for the package used in my rules > - Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png. > - Rule_120_Triggered_Part_1_ 0 is STILL not there > - TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak) > - Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7209) Operation to list installed Resource Adapters

by Guillermo González de Agüero (JIRA)

[ https://issues.jboss.org/browse/WFLY-7209?page=com.atlassian.jira.plugin.... ] Guillermo González de Agüero commented on WFLY-7209: ---------------------------------------------------- >From what I saw, it seemed to me that the resource adapter was automatically activated even without the ironjacamar.xml descriptor. I'll have to check it. My use case is to list the currently deployed resource adapters (activated or not). As it currently works, in the web console you have to specify the deployment or module name by manually typing. This would basically allow graphical UIs to show a list of possible candidates, like it works for JDBC drivers. As a side note, the resource-adapters subsystem is not listed on deployments (https://wildscribe.github.io/Wildfly/10.0.0.Final/deployment/index.html). Are there any technical reasons for that? Is it only present when there's an iconjacamar.xml descriptor present? > Operation to list installed Resource Adapters > --------------------------------------------- > > Key: WFLY-7209 > URL: https://issues.jboss.org/browse/WFLY-7209 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Reporter: Guillermo González de Agüero > Assignee: Stefano Maestri > Fix For: 10.1.0.Final > > > Currently there's no way to list all the installed Resource Adapters. Only configured resource adapters can be queried. However, they are automatically enabled at deployment time. > I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers. This would allow HAL to provide a wizard of available options when configuring them. > The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list() -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management

by Bill Tuminaro (JIRA)

Bill Tuminaro created DROOLS-1313: ------------------------------------- Summary: Memory Leak - but is this a supported scenario for Dynamic rule management Key: DROOLS-1313 URL: https://issues.jboss.org/browse/DROOLS-1313 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.3.0.Final Reporter: Bill Tuminaro Assignee: Mario Fusco Attachments: SAVE_SimpleTest.java, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/). However, I am not sure this is a supported scenario. If this is a supported approach this needs to get fixed, otherwise we need to use another approach. The attached source does this: +*Initialize stuff*+ - Create a new ReleaseId - Create a new KieFileSystem - Generate and write the PomXML for the ReleaseId created above - Create a new KieModuleModel - Create a new KieBaseModel - Write the ModuleModel XML to the KieFileSystem - Write 2 rules into the KieFileSystem +*1st build and dump*+ - Create a new KieBuilder - Do a buildall() with the KieBuilder - Create a new KieContainer - Create a new KieSession from the KieContainer - Print out the rules in the KieContainer for the package used in my rules - Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected. +*2nd build and dump*+ - Delete 2 rules from the KieFileSystem created above - Call incrementalBuild() on the KieBuilder created above - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above - Add 2 new rules to the KieFileSystem created above - Call incrementalBuild() on the KieBuilder created above - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above - Print out the rules in the KieContainer for the package used in my rules - Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png. - Rule_120_Triggered_Part_1_ 0 is not there - Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak) +*3rd build and dump*+ - Delete 1 rule from the KieFileSystem created above - Call incrementalBuild() on the KieBuilder created above - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above - Add 2 new rules to the KieFileSystem created above - Call incrementalBuild() on the KieBuilder created above - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above - Print out the rules in the KieContainer for the package used in my rules - Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png. - Rule_120_Triggered_Part_1_ 0 is STILL not there - TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak) - Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5685) Register management resources for deployment-specific caches

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5685?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-5685: --------------------------------- Bugzilla Update: (was: Perform) > Register management resources for deployment-specific caches > ------------------------------------------------------------ > > Key: WFLY-5685 > URL: https://issues.jboss.org/browse/WFLY-5685 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5685) Register management resources for deployment-specific caches

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5685?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-5685: --------------------------------- Comment: was deleted (was: Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1276441|https://bugzilla.redhat.com/show_bug.cgi?id=1276441] from ASSIGNED to CLOSED) > Register management resources for deployment-specific caches > ------------------------------------------------------------ > > Key: WFLY-5685 > URL: https://issues.jboss.org/browse/WFLY-5685 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 10.0.0.CR4 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-7229: ------------------------------------ [~micnowak1] I had a look at your MainServlet. Your mechanism for invalidating the session is problematic. The servlet spec does not require containers to support the HttpSession interface outside the context of a request or listener. The HttpSession API already has a mechanism for controlling invalidation: http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpSession.html#s... e.g. session.setMaxInactiveInterval(10); > WFLYCLWEBUT0001 for server-side invalidated sessions > ---------------------------------------------------- > > Key: WFLY-7229 > URL: https://issues.jboss.org/browse/WFLY-7229 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes. > Reporter: Michał Nowakowski > Assignee: Paul Ferraro > Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz > > > Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following: > - a session is assigned (or created, if none existed before) > - its details are printed and the browser is told to refresh after 20 seconds > - before the browser refreshes, the session is invalidated server-side by separate thread. > Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors: > - The first stacktrace happens when the thread invalidates the session. > - The second stacktrace happens, when the browser refreshes. The user sees "Error 500". > - Then, after a minute or so, I get the last one. It then repeats periodically. > We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-7229. ------------------------------ Resolution: Rejected > WFLYCLWEBUT0001 for server-side invalidated sessions > ---------------------------------------------------- > > Key: WFLY-7229 > URL: https://issues.jboss.org/browse/WFLY-7229 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes. > Reporter: Michał Nowakowski > Assignee: Paul Ferraro > Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz > > > Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following: > - a session is assigned (or created, if none existed before) > - its details are printed and the browser is told to refresh after 20 seconds > - before the browser refreshes, the session is invalidated server-side by separate thread. > Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors: > - The first stacktrace happens when the thread invalidates the session. > - The second stacktrace happens, when the browser refreshes. The user sees "Error 500". > - Then, after a minute or so, I get the last one. It then repeats periodically. > We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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: --------------------------------------- Sounds good if Java 9 is released as scheduled. :-p > 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, 10 months

1
0
0 / 0

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

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ] Scott Marlow commented on JASSIST-261: -------------------------------------- [~chiba] I changed my mind. :-) How about if we first release master as 3.21.0 and then merge test/java9-jigsaw to master and release as 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3636) Improve monitoring of JMS pooled connection in JBoss CLI

by Will Tatam (JIRA)

[ https://issues.jboss.org/browse/WFLY-3636?page=com.atlassian.jira.plugin.... ] Will Tatam commented on WFLY-3636: ---------------------------------- Great :) > Improve monitoring of JMS pooled connection in JBoss CLI > -------------------------------------------------------- > > Key: WFLY-3636 > URL: https://issues.jboss.org/browse/WFLY-3636 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 8.1.0.Final > Environment: JBoss EAP 6.x > Reporter: Tom Ross > Assignee: Jeff Mesnil > Fix For: 11.0.0.Alpha1 > > > At the moment there is no way of monitoring pooled JMS connections in JBoss CLI. It would be nice if there was some information available similar to what is available for JDBC pools: > {noformat} > "pool" => { > "ActiveCount" => "0", > "AvailableCount" => "0", > "AverageBlockingTime" => "0", > "AverageCreationTime" => "0", > "CreatedCount" => "0", > "DestroyedCount" => "0", > "InUseCount" => "0", > "MaxCreationTime" => "0", > "MaxUsedCount" => "0", > "MaxWaitCount" => "0", > "MaxWaitTime" => "0", > "TimedOut" => "0", > "TotalBlockingTime" => "0", > "TotalCreationTime" => "0", > "statistics-enabled" => false > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-398) Authorization decisions for identity manipulation

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-398?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-398: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Authorization decisions for identity manipulation > ------------------------------------------------- > > Key: ELY-398 > URL: https://issues.jboss.org/browse/ELY-398 > Project: WildFly Elytron > Issue Type: Task > Components: Realms > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > > We need to ensure we have appropriate permissions checks in place where one identity is manipulating another identity. > It is possible the subsystem will take a lot of the responsibility but lets start here with an issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-181) Review JACC in Servlet and EJB subsystems

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-181?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-181: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Review JACC in Servlet and EJB subsystems > ----------------------------------------- > > Key: ELY-181 > URL: https://issues.jboss.org/browse/ELY-181 > Project: WildFly Elytron > Issue Type: Sub-task > Components: API / SPI > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-298) load-from/uri keystore xsd/parser mismatch

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-298?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-298: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > load-from/uri keystore xsd/parser mismatch > ------------------------------------------ > > Key: ELY-298 > URL: https://issues.jboss.org/browse/ELY-298 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Kabir Khan > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > > The xsd has > {code} > <xsd:complexType name="key-store-type"> > <xsd:sequence minOccurs="1" maxOccurs="1"> >  > <xsd:choice minOccurs="1" maxOccurs="1"> > <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/> > <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/> > <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/> > {code} > The parser seems to look for 'uri' rather than 'load-from' -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-211) Client-side trust store configuration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-211?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-211: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Client-side trust store configuration > ------------------------------------- > > Key: ELY-211 > URL: https://issues.jboss.org/browse/ELY-211 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta11 > > > Lest I forget. The client needs the ability to supplement the default trust store, to restrict the set of acceptable peer certificates/signers, for mutual authentication purposes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-212) Client-side SSL context configuration is subtly wrong

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-212?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-212: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Client-side SSL context configuration is subtly wrong > ----------------------------------------------------- > > Key: ELY-212 > URL: https://issues.jboss.org/browse/ELY-212 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta11 > > > SSL context client-side configuration is problematic in that the SSL context is not (and cannot be) cached. This means that we lose SSL session reuse and other benefits which may cause problems for users. > However we also cannot just cache an SSL context on a configuration either - the client credentials may vary on each request, causing leakage between identities. > What we need to do is have a separate SSL context client configuration mechanism, and use the generic client context configuration to reference this SSL context client configuration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-449) Add CredentialStore support to Elytron client configuration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-449?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-449: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Add CredentialStore support to Elytron client configuration > ----------------------------------------------------------- > > Key: ELY-449 > URL: https://issues.jboss.org/browse/ELY-449 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Client, Credential Store > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-457) SASL SAML Authentication Mechanism

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-457?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-457: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > SASL SAML Authentication Mechanism > ---------------------------------- > > Key: ELY-457 > URL: https://issues.jboss.org/browse/ELY-457 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SASL > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > > https://tools.ietf.org/html/rfc6595 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-444) AuthorizationIdentity and PermissionMapper

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-444?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-444: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > AuthorizationIdentity and PermissionMapper > ------------------------------------------ > > Key: ELY-444 > URL: https://issues.jboss.org/browse/ELY-444 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI, Realms > Reporter: David Lloyd > Fix For: 1.1.0.Beta11 > > > When we initially designed the PermissionMapper we went to certain lengths to avoid exposing details of the realm. But now as the API has evolved it is clear that the permission mapper will need access to more information. The AuthorizationIdentity (or perhaps another object which includes the AuthorizationIdentity) should be made available to the permission mapper. > In addition, this object could be expanded to include more information about the authentication, for example mechanism-specific information, which can feed into the authorization decision and could be useful for other things. Examples include: authentication timestamp, mechanism name/kind, forwarding credentials, and other attributes which derive from the mechanism as opposed to the identity. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-455) OAuth2 Credential Store

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-455?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-455: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > OAuth2 Credential Store > ----------------------- > > Key: ELY-455 > URL: https://issues.jboss.org/browse/ELY-455 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Credential Store > Reporter: David Lloyd > Fix For: 1.1.0.Beta11 > > > Need an OAuth2 credential store which can acquire a cached OAuth2 token or instigate a new authentication. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-456) HTTP SAML Authentication Mechanism

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-456?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-456: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > HTTP SAML Authentication Mechanism > ---------------------------------- > > Key: ELY-456 > URL: https://issues.jboss.org/browse/ELY-456 > Project: WildFly Elytron > Issue Type: Feature Request > Components: HTTP > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-433) Support verification of a users certificate against an LDAP Server

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-433?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-433: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Support verification of a users certificate against an LDAP Server > ------------------------------------------------------------------ > > Key: ELY-433 > URL: https://issues.jboss.org/browse/ELY-433 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms, SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Fix For: 1.1.0.Beta11 > > > LDAP realm should be able to authenticate user using user certificate. > This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-559) Token-based authentication should forward authentication

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-559?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-559: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Token-based authentication should forward authentication > -------------------------------------------------------- > > Key: ELY-559 > URL: https://issues.jboss.org/browse/ELY-559 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Mechanisms > Reporter: David Lloyd > Fix For: 1.1.0.Beta11 > > > Mechanisms that handle BearerTokenCredetials (ELY-557) should forward them as public or private credentials (ELY-473 / https://github.com/wildfly-security/wildfly-elytron/pull/434 ). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-522) Add callbacks for persisting and restoring a SecurityIdentity

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-522?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-522: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Add callbacks for persisting and restoring a SecurityIdentity > ------------------------------------------------------------- > > Key: ELY-522 > URL: https://issues.jboss.org/browse/ELY-522 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-524) Caching support in the LDAP realm

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-524?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-524: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Caching support in the LDAP realm > --------------------------------- > > Key: ELY-524 > URL: https://issues.jboss.org/browse/ELY-524 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms > Reporter: David Lloyd > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta11 > > > The LDAP realm should use a caching strategy to avoid excessive database load in the presence of per-request authentication traffic. > The realm implementation could maintain a synchronized LRU cache of one-time-initialize references to a cached DirContext or Attributes or binding or some combination of these. Because the cache is synchronized, the one-time-initialize object would be added under the lock and then the lock released before the object is populated and returned as a cached credential, allowing atomic action with a minimum of contention. > For each cached entity, a NamingListener could be established which would invalidate (or possibly update) the cached value as the database changes. > Alternatively, a NamingListener could be established for all identities, and each update would invalidate or update any cached values corresponding to the DN or resolved name. > This is a complex design topic so discussion is welcome. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-489) Add JavaDoc for the 'org.wildfly.security.mechanism' package and sub packages.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-489?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-489: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Add JavaDoc for the 'org.wildfly.security.mechanism' package and sub packages. > ------------------------------------------------------------------------------ > > Key: ELY-489 > URL: https://issues.jboss.org/browse/ELY-489 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-490) Add JavaDoc for the 'org.wildfly.security.ssl' package and sub packages.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-490?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-490: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Add JavaDoc for the 'org.wildfly.security.ssl' package and sub packages. > ------------------------------------------------------------------------ > > Key: ELY-490 > URL: https://issues.jboss.org/browse/ELY-490 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-509) Multi Step HTTP Authentication

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-509?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-509: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Multi Step HTTP Authentication > ------------------------------ > > Key: ELY-509 > URL: https://issues.jboss.org/browse/ELY-509 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Farah Juma > Fix For: 1.1.0.Beta11 > > > This is a variation of FORM authentication and closely related to ELY-508. > The scenario would be prompt for a username, then prompt for a password and if the password is valid and the account supports OTP prompt for the OTP. > The mechanism may also be responsible for sending the OTP but that is probably a side topic. > I have raised this in terms of being a HTTP mechanism but the main point we need to ensure is covered is the requirements about identifying what checks are required for a specific user and tracking they are all complete. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-486) Add JavaDoc for the 'org.wildfly.security.credential' package and sub packages.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-486?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-486: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Add JavaDoc for the 'org.wildfly.security.credential' package and sub packages. > ------------------------------------------------------------------------------- > > Key: ELY-486 > URL: https://issues.jboss.org/browse/ELY-486 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-485) Add JavaDoc for the 'org.wildfly.security.auth.server' package and sub packages.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-485?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-485: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Add JavaDoc for the 'org.wildfly.security.auth.server' package and sub packages. > -------------------------------------------------------------------------------- > > Key: ELY-485 > URL: https://issues.jboss.org/browse/ELY-485 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-477) XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-477?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-477: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK > ---------------------------------------------------------- > > Key: ELY-477 > URL: https://issues.jboss.org/browse/ELY-477 > Project: WildFly Elytron > Issue Type: Bug > Components: Testsuite > Affects Versions: 1.1.0.Beta4 > Reporter: Ondrej Lukas > Fix For: 1.1.0.Beta11 > > > Test XmlConfigurationTest.testWrongRuleOrder fails with IBM JDK with: > {code} > expected:<-1> but was:<7> > and stacktrace: > java.lang.AssertionError: expected:<-1> but was:<7> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:555) > at org.junit.Assert.assertEquals(Assert.java:542) > at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:96) > ... > {code} > It is caused by undefined line number of XML parsing failure for IBM JDK. > Stacktrace of checked XMLStreamException for IBM JDK: > {code} > org.wildfly.client.config.ConfigXMLParseException: > CONF000005: Unexpected element "{urn:elytron:1.0}match-host" encountered > at authentication-client.xml: > at org.wildfly.client.config.ConfigurationXMLStreamReader.unexpectedElement(ConfigurationXMLStreamReader.java:257) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRuleType(ElytronXmlParser.java:341) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRulesType(ElytronXmlParser.java:238) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:181) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:118) > at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:93) > ... > {code} > Stacktrace of checked XMLStreamException for Oracle JDK: > {code} > org.wildfly.client.config.ConfigXMLParseException: > CONF000005: Unexpected element "{urn:elytron:1.0}match-host" encountered > at authentication-client.xml:7:39: > at org.wildfly.client.config.ConfigurationXMLStreamReader.unexpectedElement(ConfigurationXMLStreamReader.java:257) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRuleType(ElytronXmlParser.java:341) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientRulesType(ElytronXmlParser.java:238) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:181) > at org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:118) > at org.wildfly.security.auth.client.XmlConfigurationTest.testWrongRuleOrder(XmlConfigurationTest.java:93) > ... > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-625) Include the client schema in the jar

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-625?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-625: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Include the client schema in the jar > ------------------------------------ > > Key: ELY-625 > URL: https://issues.jboss.org/browse/ELY-625 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > > We need to get the schema into the jar so when assembled in a WildFly feature pack it can be extracted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-624) Add support for SSO and Clustered SSO

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-624?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-624: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Add support for SSO and Clustered SSO > ------------------------------------- > > Key: ELY-624 > URL: https://issues.jboss.org/browse/ELY-624 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Pedro Igor > Priority: Critical > Fix For: 1.1.0.Beta11 > > > This issue is to cover the APIs / SPIs and some implementation where Elytron is to be used with container managed SSO / Clustered SSO. > By this we mean authentication mechanisms similar to HTTP Form where we want the resulting SecurityIdentity to be re-used across different HTTP context and possibly in the clustered case across different nodes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-617) Review 'null' handling for MechanismConfiguration and MechanismRealmConfiguration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-617?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-617: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Review 'null' handling for MechanismConfiguration and MechanismRealmConfiguration > --------------------------------------------------------------------------------- > > Key: ELY-617 > URL: https://issues.jboss.org/browse/ELY-617 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > > Javadoc states various NameRewriter instances will not be null, implementation suggests otherwise. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-613) Some nested classes should be considered to be static nested in Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-613?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-613: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Some nested classes should be considered to be static nested in Elytron > ----------------------------------------------------------------------- > > Key: ELY-613 > URL: https://issues.jboss.org/browse/ELY-613 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: static_analysis > Fix For: 1.1.0.Beta11 > > > There are some inner classes in Elytron which should be considered to be static nested to avoid dependency on their outer class. Following nested classes should be considered: > * LoadedIdentity and Identity from org.wildfly.security.auth.realm.FileSystemSecurityRealm > * DecoderState from org.wildfly.security.asn1.DERDecoder > * AccountEntry from org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm > * JaasAuthorizationIdentity and DefaultCallbackHandler from org.wildfly.security.auth.realm.JaasSecurityRealm > * LoadKey from org.wildfly.security.keystore.AtomicLoadKeyStore -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-609) Unguarded read in ElytronPolicyConfiguration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-609: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Unguarded read in ElytronPolicyConfiguration > -------------------------------------------- > > Key: ELY-609 > URL: https://issues.jboss.org/browse/ELY-609 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: static_analysis > Fix For: 1.1.0.Beta11 > > > Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-606) Wrap the match elements with an outer match element.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-606?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-606: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Wrap the match elements with an outer match element. > ---------------------------------------------------- > > Key: ELY-606 > URL: https://issues.jboss.org/browse/ELY-606 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta11 > > > For each match type we support at most one definition of each - by adding a wrapper element we can use xsd:all to more accurately reflect this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-601) Adjust all AuthenticationConfiguration 'use' methods to more closely match the schema

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-601?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-601: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Adjust all AuthenticationConfiguration 'use' methods to more closely match the schema > ------------------------------------------------------------------------------------- > > Key: ELY-601 > URL: https://issues.jboss.org/browse/ELY-601 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta11 > > > Within the schema a lot of these are configured using 'set'*' elements - switch the methods over to set as well. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-600) Remove minOccurs="1" and maxOccurs="1" from the schema as these are the defaults.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-600?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-600: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Remove minOccurs="1" and maxOccurs="1" from the schema as these are the defaults. > --------------------------------------------------------------------------------- > > Key: ELY-600 > URL: https://issues.jboss.org/browse/ELY-600 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-583) Add ability for outbound clients to directly consume IdentityCredentials

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-583?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-583: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Add ability for outbound clients to directly consume IdentityCredentials > ------------------------------------------------------------------------ > > Key: ELY-583 > URL: https://issues.jboss.org/browse/ELY-583 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta11 > > > Outbound clients can gain substantial flexibility by being able to use {{IdentityCredentials}} directly. This allows a non-type-specific object like a {{byte[]}} to be interpreted as many different types of credentials. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-595) Ability to provide CallbackHandler and SSLContext when AuthenticationConfiguration dynamically loaded.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-595?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-595: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Ability to provide CallbackHandler and SSLContext when AuthenticationConfiguration dynamically loaded. > ------------------------------------------------------------------------------------------------------ > > Key: ELY-595 > URL: https://issues.jboss.org/browse/ELY-595 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-649) Make the exists and create methods on HttpScope default

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-649?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-649: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Make the exists and create methods on HttpScope default > ------------------------------------------------------- > > Key: ELY-649 > URL: https://issues.jboss.org/browse/ELY-649 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI, HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-643) On the SSLContextBuilder support setUseCipherSuitesOrder

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-643?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-643: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > On the SSLContextBuilder support setUseCipherSuitesOrder > -------------------------------------------------------- > > Key: ELY-643 > URL: https://issues.jboss.org/browse/ELY-643 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.1.0.Beta11 > > > Currently we hard code this value to 'true' which should remain the default as the OpenSSL style cipher suite selection includes preferred mechanism ordering - however it should be possible to override this and set it to false. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-639) SecurityIdentity and PeerIdentity should have more runAs* variants

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-639?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-639: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > SecurityIdentity and PeerIdentity should have more runAs* variants > ------------------------------------------------------------------ > > Key: ELY-639 > URL: https://issues.jboss.org/browse/ELY-639 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: David Lloyd > Fix For: 1.1.0.Beta11 > > > The XxxIdentity classes have fewer runAs modes than (for example) Contextual objects do. Unifying these types would be ideal, but I'd settle for adding the missing types, including the {{Exception*}} functional types from WildFly Common. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-628) Allow JWT-based token realms to operate in parse-only mode

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-628?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-628: --------------------------------- Fix Version/s: 1.1.0.Beta11 (was: 1.1.0.Beta10) > Allow JWT-based token realms to operate in parse-only mode > ---------------------------------------------------------- > > Key: ELY-628 > URL: https://issues.jboss.org/browse/ELY-628 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Affects Versions: 1.1.0.Beta8 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta11 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-648) Release WildFly Elytron 1.1.0.Beta10

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-648?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-648. ---------------------------------- Resolution: Done > Release WildFly Elytron 1.1.0.Beta10 > ------------------------------------ > > Key: ELY-648 > URL: https://issues.jboss.org/browse/ELY-648 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta10 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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: --------------------------------------- Yes, just the building process (by maven) needs Java 9. Since the code refers to a class available only in Java 9 but that class is not instantiated or accessed if the JVM is not Java 9, the code runs in Java 8. The class files are compiled to be able to run even in Java 6. > 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, 10 months

1
0
0 / 0

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

by Steve Ebersole (JIRA)

[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ] Steve Ebersole commented on JASSIST-261: ---------------------------------------- [~chiba] the jar [~smarlow] built for me that I used in testing Hibernate was Java 8 compatible (I was able to run the Hibernate tests fine using that SNAPSHOT and Java 8). Do you mean that just the build is sensitive to the JDK used? Not being able to work in both Java 8 and 9 at runtime is going to be a big headache. > 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2098: -------------------------------- The NAMING part is done in https://issues.jboss.org/browse/JGRP-2104 > Discovery: reduce messages when IpAddressUUID is used > ----------------------------------------------------- > > Key: JGRP-2098 > URL: https://issues.jboss.org/browse/JGRP-2098 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: LESS_PING.java > > > Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase. > Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID. > Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2098. ---------------------------- Resolution: Done > Discovery: reduce messages when IpAddressUUID is used > ----------------------------------------------------- > > Key: JGRP-2098 > URL: https://issues.jboss.org/browse/JGRP-2098 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: LESS_PING.java > > > Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase. > Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID. > Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2104) NAMING: provide logical names when IpAddressUUID is used as addresses

by Bela Ban (JIRA)

Bela Ban created JGRP-2104: ------------------------------ Summary: NAMING: provide logical names when IpAddressUUID is used as addresses Key: JGRP-2104 URL: https://issues.jboss.org/browse/JGRP-2104 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0 This is a new protocol, typically added somewhere above {{NAKACK2}}. When {{TP.use_ip_addr}} is true, {{IpAddressUUID}} addresses will be used. If {{Discovery.max_rank_to_reply}} is less than the max rank of the cluster view, not all members will receive discovery responses. They therefore won't have a mapping between the address and the logical name for all members. {{NAMING}} fixes this by having the joiner multicast the address:name mapping after joining, and by everyone sending their mapping to the newly joined member as well. Note that this protocol is not strictly necessary; as {{IpAddressUUID}} addresses will also work without logical names mapped to them, but it improves legibility, e.g. of logs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3636) Improve monitoring of JMS pooled connection in JBoss CLI

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-3636?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFLY-3636: ----------------------------------- [~will.tatam] yes, that's targeted for EAP 7.1.0 GA > Improve monitoring of JMS pooled connection in JBoss CLI > -------------------------------------------------------- > > Key: WFLY-3636 > URL: https://issues.jboss.org/browse/WFLY-3636 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 8.1.0.Final > Environment: JBoss EAP 6.x > Reporter: Tom Ross > Assignee: Jeff Mesnil > Fix For: 11.0.0.Alpha1 > > > At the moment there is no way of monitoring pooled JMS connections in JBoss CLI. It would be nice if there was some information available similar to what is available for JDBC pools: > {noformat} > "pool" => { > "ActiveCount" => "0", > "AvailableCount" => "0", > "AverageBlockingTime" => "0", > "AverageCreationTime" => "0", > "CreatedCount" => "0", > "DestroyedCount" => "0", > "InUseCount" => "0", > "MaxCreationTime" => "0", > "MaxUsedCount" => "0", > "MaxWaitCount" => "0", > "MaxWaitTime" => "0", > "TimedOut" => "0", > "TotalBlockingTime" => "0", > "TotalCreationTime" => "0", > "statistics-enabled" => false > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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 just merged all the commits (bug fixes) to master into test/java9-jigsaw branch. The only problem of test/java9-jigsaw is the code refers to a class available only in Java 9. So maven build will fail if the compiler is not Java 9's. I will release the head of master branch as release 3.21.0-GA and also test/java9-jigsaw branch as maybe 3.22.0-CR1 (or 3.22.0-Java9-CR1 for clarification? Which naming scheme is appropriate?). > 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7241) Upgrade Narayana to 5.3.5.Final

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-7241?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated WFLY-7241: -------------------------------- Description: https://issues.jboss.org/browse/JBTM/fixforversion/12331277/?selectedTab=... > Upgrade Narayana to 5.3.5.Final > ------------------------------- > > Key: WFLY-7241 > URL: https://issues.jboss.org/browse/WFLY-7241 > Project: WildFly > Issue Type: Component Upgrade > Components: Transactions > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > https://issues.jboss.org/browse/JBTM/fixforversion/12331277/?selectedTab=... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1487) Include indexed properties in the suggestion list if no completer exists

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1487?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Śmietanko resolved WFCORE-1487. ---------------------------------------------- Resolution: Deferred Replaced by https://issues.jboss.org/browse/WFCORE-1840 > Include indexed properties in the suggestion list if no completer exists > ------------------------------------------------------------------------ > > Key: WFCORE-1487 > URL: https://issues.jboss.org/browse/WFCORE-1487 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Affects Versions: 2.1.0.Final > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > Fix For: 3.0.0.Alpha1, 2.2.0.CR1 > > > Command parameters that can be specified by either an index and a name, but have no value completer are not included in the tab completion list. > For example patch rollback tab completion does not show --patch-id > {noformat} > [disconnected /] patch rollback -- > --override-all --override-modules --override= --preserve= --reset-configuration= --rollback-to > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3636) Improve monitoring of JMS pooled connection in JBoss CLI

by Will Tatam (JIRA)

[ https://issues.jboss.org/browse/WFLY-3636?page=com.atlassian.jira.plugin.... ] Will Tatam commented on WFLY-3636: ---------------------------------- As there is a pull request for EAP, does this mean we might see merged in as part of 7.x ? > Improve monitoring of JMS pooled connection in JBoss CLI > -------------------------------------------------------- > > Key: WFLY-3636 > URL: https://issues.jboss.org/browse/WFLY-3636 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 8.1.0.Final > Environment: JBoss EAP 6.x > Reporter: Tom Ross > Assignee: Jeff Mesnil > Fix For: 11.0.0.Alpha1 > > > At the moment there is no way of monitoring pooled JMS connections in JBoss CLI. It would be nice if there was some information available similar to what is available for JDBC pools: > {noformat} > "pool" => { > "ActiveCount" => "0", > "AvailableCount" => "0", > "AverageBlockingTime" => "0", > "AverageCreationTime" => "0", > "CreatedCount" => "0", > "DestroyedCount" => "0", > "InUseCount" => "0", > "MaxCreationTime" => "0", > "MaxUsedCount" => "0", > "MaxWaitCount" => "0", > "MaxWaitTime" => "0", > "TimedOut" => "0", > "TotalBlockingTime" => "0", > "TotalCreationTime" => "0", > "statistics-enabled" => false > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1840) patch rollback should suggest installed patch ids

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1840?page=com.atlassian.jira.plugi... ] Bartosz Spyrko-Śmietanko moved JBEAP-6249 to WFCORE-1840: --------------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1840 (was: JBEAP-6249) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: CLI (was: CLI) Target Release: (was: 7.1.0.GA) Affects Version/s: 3.0.0.Alpha8 (was: 7.1.0.DR5) Fix Version/s: (was: 7.0.4.GA) > patch rollback should suggest installed patch ids > ------------------------------------------------- > > Key: WFCORE-1840 > URL: https://issues.jboss.org/browse/WFCORE-1840 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Affects Versions: 3.0.0.Alpha8 > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > Labels: downstream_dependency > > patch rollback <TAB> currently suggests named parameters, but it doesn't give user a clue that a patch id is needed. eg: > {noformat} > [disconnected /] patch rollback -- > --override-all --override-modules --override= --preserve= --reset-configuration= --rollback-to > {noformat} > A list of installed patches should be added to the suggestions. If there are no patches installed on the system, 'rollback' action should not be suggested on patch <TAB> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

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

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ] Scott Marlow edited comment on JASSIST-261 at 9/29/16 9:30 AM: --------------------------------------------------------------- [~chiba] I think it is too early to merge the java9-only branch to master. After thinking more about your questions, I would like to release a javassist for Java9 EA, so that other projects like Hibernate can consume that. It would be good if this javassist release is marked CR1 or something like that, to reflect that its for JDK9 EA (e.g. not certain to work with JDK9 final). If we also release 3.21.0 for the master branch soon, that also sounds good to me. was (Author: smarlow): [~chiba] I think it is too early to merge the java9-only branch to master. After thinking more about your questions, I would like to release a javassist for Java9 EA, so that other projects like Hibernate can consume that. It would be good if this javassist release is marked marked CR1 or something like that, to reflect that its for JDK9 EA (e.g. not certain to work with JDK9 final). If we also release 3.21.0 for the master branch soon, that also sounds good to me. > 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, 10 months

1
0
0 / 0

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

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ] Scott Marlow commented on JASSIST-261: -------------------------------------- [~chiba] I think it is too early to merge the java9-only branch to master. After thinking more about your questions, I would like to release a javassist for Java9 EA, so that other projects like Hibernate can consume that. It would be good if this javassist release is marked marked CR1 or something like that, to reflect that its for JDK9 EA (e.g. not certain to work with JDK9 final). If we also release 3.21.0 for the master branch soon, that also sounds good to me. > 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3636) Improve monitoring of JMS pooled connection in JBoss CLI

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-3636?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFLY-3636: ----------------------------------- JBCA-1330 prevents the XA stats to be updated (but the pool stats work as expected). > Improve monitoring of JMS pooled connection in JBoss CLI > -------------------------------------------------------- > > Key: WFLY-3636 > URL: https://issues.jboss.org/browse/WFLY-3636 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 8.1.0.Final > Environment: JBoss EAP 6.x > Reporter: Tom Ross > Assignee: Jeff Mesnil > Fix For: 11.0.0.Alpha1 > > > At the moment there is no way of monitoring pooled JMS connections in JBoss CLI. It would be nice if there was some information available similar to what is available for JDBC pools: > {noformat} > "pool" => { > "ActiveCount" => "0", > "AvailableCount" => "0", > "AverageBlockingTime" => "0", > "AverageCreationTime" => "0", > "CreatedCount" => "0", > "DestroyedCount" => "0", > "InUseCount" => "0", > "MaxCreationTime" => "0", > "MaxUsedCount" => "0", > "MaxWaitCount" => "0", > "MaxWaitTime" => "0", > "TimedOut" => "0", > "TotalBlockingTime" => "0", > "TotalCreationTime" => "0", > "statistics-enabled" => false > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7241) Upgrade Narayana to 5.3.5.Final

by Tom Jenkinson (JIRA)

Tom Jenkinson created WFLY-7241: ----------------------------------- Summary: Upgrade Narayana to 5.3.5.Final Key: WFLY-7241 URL: https://issues.jboss.org/browse/WFLY-7241 Project: WildFly Issue Type: Component Upgrade Components: Transactions Reporter: Tom Jenkinson Assignee: Tom Jenkinson -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7240) CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7240?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7240: --------------------------------- Summary: CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split (was: CacheRegistry is missing entries (e.g. client mappings) following a merge) > CacheRegistry is missing entries (e.g. client mappings) following a merge after a cluster split > ----------------------------------------------------------------------------------------------- > > Key: WFLY-7240 > URL: https://issues.jboss.org/browse/WFLY-7240 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > > One of the manifestation of the issue: > # start 2 nodes with SLSB with TUNNEL transport > # start both nodes creating 2 clusters (or partitions) > # start ejb client > # start GossipRouter and wait for merge > # ejb client keeps talking only to known node; never receives a topology update > This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7240) CacheRegistry is missing entries (e.g. client mappings) following a merge

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7240?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-7240: --------------------------------- Description: One of the manifestation of the issue: # start 2 nodes with SLSB with TUNNEL transport # start both nodes creating 2 clusters (or partitions) # start ejb client # start GossipRouter and wait for merge # ejb client keeps talking only to known node; never receives a topology update This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges. was: One of the manifestation of the issue: # start 2 nodes with SLSB with TUNNEL transport # start both nodes creating 2 partitie # start ejb client # start GossipRouter and wait for merge # ejb client keeps talking only to 1st node, never receives a topology update This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges. > CacheRegistry is missing entries (e.g. client mappings) following a merge > ------------------------------------------------------------------------- > > Key: WFLY-7240 > URL: https://issues.jboss.org/browse/WFLY-7240 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final, 10.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Critical > > One of the manifestation of the issue: > # start 2 nodes with SLSB with TUNNEL transport > # start both nodes creating 2 clusters (or partitions) > # start ejb client > # start GossipRouter and wait for merge > # ejb client keeps talking only to known node; never receives a topology update > This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7240) CacheRegistry is missing entries (e.g. client mappings) following a merge

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-7240: ------------------------------------ Summary: CacheRegistry is missing entries (e.g. client mappings) following a merge Key: WFLY-7240 URL: https://issues.jboss.org/browse/WFLY-7240 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final, 10.0.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Priority: Critical One of the manifestation of the issue: # start 2 nodes with SLSB with TUNNEL transport # start both nodes creating 2 partitie # start ejb client # start GossipRouter and wait for merge # ejb client keeps talking only to 1st node, never receives a topology update This is because org.wildfly.clustering.server.registry.CacheRegistry#topologyChanged does not handle cluster merges. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7239) Upgrade HAL to 2.9.0.Alpha3

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-7239?page=com.atlassian.jira.plugin.... ] Harald Pehl updated WFLY-7239: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/9192) > Upgrade HAL to 2.9.0.Alpha3 > --------------------------- > > Key: WFLY-7239 > URL: https://issues.jboss.org/browse/WFLY-7239 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7239) Upgrade HAL to 2.9.0.Alpha3

by Harald Pehl (JIRA)

Harald Pehl created WFLY-7239: --------------------------------- Summary: Upgrade HAL to 2.9.0.Alpha3 Key: WFLY-7239 URL: https://issues.jboss.org/browse/WFLY-7239 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions

by Michał Nowakowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ] Michał Nowakowski edited comment on WFLY-7229 at 9/29/16 8:51 AM: ------------------------------------------------------------------ Clustering? Could be, sure. Race? Well, this is just a demo. The problem is, we need server-side session invalidation to work. It works in 10.0, and even in 10.1 if clustering is off. Some SSO solutions rely on this, like Apereo CAS (formerly Jasig CAS) when configured to use back-channel - which is our case. was (Author: micnowak1): Clustering? Could be, sure. Race? Well, this is just a demo. The problem is, we need server-side session invalidation to work. It works in 10.0, and even in 10.1 if clustering (?) is off. Some SSO solutions rely on this, like Apereo CAS (formerly Jasig CAS) when configured to use back-channel - which is our case. > WFLYCLWEBUT0001 for server-side invalidated sessions > ---------------------------------------------------- > > Key: WFLY-7229 > URL: https://issues.jboss.org/browse/WFLY-7229 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes. > Reporter: Michał Nowakowski > Assignee: Paul Ferraro > Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz > > > Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following: > - a session is assigned (or created, if none existed before) > - its details are printed and the browser is told to refresh after 20 seconds > - before the browser refreshes, the session is invalidated server-side by separate thread. > Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors: > - The first stacktrace happens when the thread invalidates the session. > - The second stacktrace happens, when the browser refreshes. The user sees "Error 500". > - Then, after a minute or so, I get the last one. It then repeats periodically. > We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions

by Michał Nowakowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ] Michał Nowakowski commented on WFLY-7229: ----------------------------------------- Clustering? Could be, sure. Race? Well, this is just a demo. The problem is, we need server-side session invalidation to work. It works in 10.0, and even in 10.1 if clustering (?) is off. Some SSO solutions rely on this, like Apereo CAS (formerly Jasig CAS) when configured to use back-channel - which is our case. > WFLYCLWEBUT0001 for server-side invalidated sessions > ---------------------------------------------------- > > Key: WFLY-7229 > URL: https://issues.jboss.org/browse/WFLY-7229 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 10.1.0.Final > Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes. > Reporter: Michał Nowakowski > Assignee: Paul Ferraro > Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz > > > Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following: > - a session is assigned (or created, if none existed before) > - its details are printed and the browser is told to refresh after 20 seconds > - before the browser refreshes, the session is invalidated server-side by separate thread. > Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors: > - The first stacktrace happens when the thread invalidates the session. > - The second stacktrace happens, when the browser refreshes. The user sees "Error 500". > - Then, after a minute or so, I get the last one. It then repeats periodically. > We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6297) Identify problems introduced with new JDK9 versioning scheme

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6297?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-6297: ----------------------------------- Google Guava was removed from build, so is is no longer an issue. > Identify problems introduced with new JDK9 versioning scheme > ------------------------------------------------------------ > > Key: WFLY-6297 > URL: https://issues.jboss.org/browse/WFLY-6297 > Project: WildFly > Issue Type: Sub-task > Components: Build System > Affects Versions: 10.0.0.Final > Reporter: Richard Opalka > Assignee: Richard Opalka > > JDK9 will introduce new versioning scheme described here: > http://openjdk.java.net/projects/verona/ > We need to identify WildFly components that are realying on > these properties. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1839) Map completion

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-1839: -------------------------------------------- Summary: Map completion Key: WFCORE-1839 URL: https://issues.jboss.org/browse/WFCORE-1839 Project: WildFly Core Issue Type: Feature Request Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise At least we should propose the '{' character when a property of type Map is to be completed, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5842) Upgrade google guava from 18 to 19

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5842?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-5842. ----------------------------- Fix Version/s: 11.0.0.Alpha1 Resolution: Won't Do Guava was removed from WildFly as it was only used by Weld, which has stopped using it in 2.4.0 > Upgrade google guava from 18 to 19 > ---------------------------------- > > Key: WFLY-5842 > URL: https://issues.jboss.org/browse/WFLY-5842 > Project: WildFly > Issue Type: Component Upgrade > Affects Versions: 10.0.0.CR5 > Reporter: Frank Langelage > Assignee: Jason Greene > Priority: Minor > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1795) :query() operation fails with IllegalArgumentException when specifying a where parameter

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1795?page=com.atlassian.jira.plugi... ] Jean-Francois Denise resolved WFCORE-1795. ------------------------------------------ Fix Version/s: 3.0.0.Alpha8 Resolution: Done > :query() operation fails with IllegalArgumentException when specifying a where parameter > ---------------------------------------------------------------------------------------- > > Key: WFCORE-1795 > URL: https://issues.jboss.org/browse/WFCORE-1795 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Harald Pehl > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Alpha8 > > > This operation works in WFLY 10: > {code} > /host=*/server=*:query(select=["name"],where={"server-group" = "main-server-group"}) > {code} > whereas it fails with an IllegalArgumentException in WFLY 11 > Without the {{where}} parameter the operation works. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-649) Make the exists and create methods on HttpScope default

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-649: ------------------------------------ Summary: Make the exists and create methods on HttpScope default Key: ELY-649 URL: https://issues.jboss.org/browse/ELY-649 Project: WildFly Elytron Issue Type: Enhancement Components: API / SPI, HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Blocker Fix For: 1.1.0.Beta10 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1838) Upgrade to Elytron Web 1.0.0.Beta4

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-1838: ---------------------------------------- Summary: Upgrade to Elytron Web 1.0.0.Beta4 Key: WFCORE-1838 URL: https://issues.jboss.org/browse/WFCORE-1838 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha9 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1837) Upgrade to WildFly Elytron 1.1.0.Beta10

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-1837: ---------------------------------------- Summary: Upgrade to WildFly Elytron 1.1.0.Beta10 Key: WFCORE-1837 URL: https://issues.jboss.org/browse/WFCORE-1837 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha9 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-648) Release WildFly Elytron 1.1.0.Beta10

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-648: ------------------------------------ Summary: Release WildFly Elytron 1.1.0.Beta10 Key: ELY-648 URL: https://issues.jboss.org/browse/ELY-648 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta10 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2098: -------------------------------- I added attribute {{max_rank_to_reply}} to {{Discovery}}. If {{TP.use_ip_addrs}} is enabled and the rank is higher than {{max_rank_to_reply}}, then a member won't send a discovery response. This is implemented in {{PING}} and {{TCPPING}}. > Discovery: reduce messages when IpAddressUUID is used > ----------------------------------------------------- > > Key: JGRP-2098 > URL: https://issues.jboss.org/browse/JGRP-2098 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > Attachments: LESS_PING.java > > > Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase. > Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID. > Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-646) Unable to setup CLIENT_CERT authentication with elytron.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-646?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-646: ------------------------------------ Assignee: Jan Kalina (was: Darran Lofthouse) > Unable to setup CLIENT_CERT authentication with elytron. > -------------------------------------------------------- > > Key: ELY-646 > URL: https://issues.jboss.org/browse/ELY-646 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Blocker > > Following Zach's notes on [How to setup 2 way TLS|https://gitlab.cee.redhat.com/zrhoads/kbase/blob/master/eap71.elytron...] I am unable to setup it properly. User is not requested by browser for specifying client certificate and get access to application without certificate. > In log you there is: > 1. Server send request for certificate > {code} > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) *** CertificateRequest > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Types: RSA, DSS, ECDSA > ^[[0m^[[0m13:55:33,309 INFO [stdout] (default task-1) Cert Authorities: > ^[[0m^[[0m13:55:33,310 INFO [stdout] (default task-1) <CN=client> > {code} > 2. And client responds with empty certificate chain. Without asking for certificate > {code} > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) *** Certificate chain > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) <Empty> > ^[[0m^[[0m13:55:33,432 INFO [stdout] (default task-2) *** > {code} > I am attaching: > * server.log - server log with -Djavax.net.debug=all turn on. > * 2wayTLS.pcap - wireshark recording of port 8443 > * secured-app - tested application -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7226) Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7226?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7226: ---------------------------------- No need to worry, this required only trivial fix of resource definition. > Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-7226 > URL: https://issues.jboss.org/browse/WFLY-7226 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > In case when mapped-regex-realm-mapper is added through CLI and realm-map attribute is not used then IllegalArgumentException is thrown to server log instead of some CLI failure message like "realm-map may not be null". > Expcetion in server log: > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("mapped-regex-realm-mapper" => "MappedRealmMapper") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139) > at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378) > at org.wildfly.extension.elytron.RealmMapperDefinitions$MappedRegexRealmMapperAddHandler.performRuntime(RealmMapperDefinitions.java:221) > at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7226) Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7226?page=com.atlassian.jira.plugin.... ] Jan Kalina edited comment on WFLY-7226 at 9/29/16 6:16 AM: ----------------------------------------------------------- [~ivassile] No need to worry, this required only trivial fix of resource definition. was (Author: honza889): No need to worry, this required only trivial fix of resource definition. > Missing realm-map attribute for mapped-regex-realm-mapper throws IllegalArgumentException to server log > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-7226 > URL: https://issues.jboss.org/browse/WFLY-7226 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > In case when mapped-regex-realm-mapper is added through CLI and realm-map attribute is not used then IllegalArgumentException is thrown to server log instead of some CLI failure message like "realm-map may not be null". > Expcetion in server log: > {code} > ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("mapped-regex-realm-mapper" => "MappedRealmMapper") > ]): java.lang.IllegalArgumentException > at org.jboss.dmr.ModelValue.getKeys(ModelValue.java:139) > at org.jboss.dmr.ModelNode.keys(ModelNode.java:1378) > at org.wildfly.extension.elytron.RealmMapperDefinitions$MappedRegexRealmMapperAddHandler.performRuntime(RealmMapperDefinitions.java:221) > at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337) > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382) > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363) > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410) > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.Subject.doAs(Subject.java:422) > at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149) > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70) > at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1641) CLI, completion for more than one header is not working

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1641?page=com.atlassian.jira.plugi... ] Jean-Francois Denise resolved WFCORE-1641. ------------------------------------------ Fix Version/s: 3.0.0.Alpha6 Resolution: Done > CLI, completion for more than one header is not working > ------------------------------------------------------- > > Key: WFCORE-1641 > URL: https://issues.jboss.org/browse/WFCORE-1641 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Alpha6 > > > This can't be fixed until https://issues.jboss.org/browse/AESH-386 is fixed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7238) Warning of IllegalStateException on test-connection-pool for DataSources added after previous failure addition

by Lin Gao (JIRA)

Lin Gao created WFLY-7238: ----------------------------- Summary: Warning of IllegalStateException on test-connection-pool for DataSources added after previous failure addition Key: WFLY-7238 URL: https://issues.jboss.org/browse/WFLY-7238 Project: WildFly Issue Type: Bug Components: JCA Reporter: Lin Gao Assignee: Lin Gao When a data-source was failed to be added either because of missing connection-properties: {code:} /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2) {code} or missing of connection-url: {code:} /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2) {code} , it can be added by correcting the information, like: {code:} [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test") {"outcome" => "success"} {code} But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7214) Warning of IllegalStateException on test-connection-pool for DataSources added after previous failure addition

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-7214?page=com.atlassian.jira.plugin.... ] Lin Gao reassigned WFLY-7214: ----------------------------- Assignee: Lin Gao (was: Jesper Pedersen) > Warning of IllegalStateException on test-connection-pool for DataSources added after previous failure addition > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7214 > URL: https://issues.jboss.org/browse/WFLY-7214 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Lin Gao > Assignee: Lin Gao > > When a data-source was failed to be added either because of missing connection-properties: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2) > {code} > or missing of connection-url: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2) > {code} > , it can be added by correcting the information, like: > {code:} > [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test") > {"outcome" => "success"} > {code} > But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7191) alias-filter of filtering-key-store should be required in model

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7191?page=com.atlassian.jira.plugin.... ] Jan Kalina reassigned WFLY-7191: -------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > alias-filter of filtering-key-store should be required in model > --------------------------------------------------------------- > > Key: WFLY-7191 > URL: https://issues.jboss.org/browse/WFLY-7191 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Optional > > {{alias-filter}} attribute of filtering-key-store should be required in model > Elytron doesn't allow null value of {{alias-filter}} attribute of resource filtering-key-store. If I try to create filtering-key-store withou alias-filter I get: > {code} > [standalone@localhost:9990 /] /subsystem=elytron/filtering-key-store=fks:add(key-store=server) > { > "outcome" => "failed", > "failure-description" => { > "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.fks" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.fks: java.lang.IllegalArgumentException: Parameter 'filterString' may not be null > Caused by: java.lang.IllegalArgumentException: Parameter 'filterString' may not be null"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.fks"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > }, > "rolled-back" => true > } > {code} > So, {{alias-filter}} can be also defined in model as required, it means {{"nillable" => false}}. Now it is: > {code} > "alias-filter" => { > "type" => STRING, > "description" => "A filter to apply to the aliases returned from the KeyStore, can either be a comma separated list of aliases to return or one of the following formats ALL:-alias1:-alias2, NONE:+alias1:+alias2", > "expressions-allowed" => true, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > }, > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1312) Maven plug-in to auto instrument bytecode for OOPath reactivity

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1312: -------------------------------------- Summary: Maven plug-in to auto instrument bytecode for OOPath reactivity Key: DROOLS-1312 URL: https://issues.jboss.org/browse/DROOLS-1312 Project: Drools Issue Type: Feature Request Components: tools Affects Versions: 6.5.0.CR2 Reporter: Matteo Mortari Assignee: Matteo Mortari Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1334) Add DataSource to ManagementRepository only after deployed successfully

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1334?page=com.atlassian.jira.plugin... ] Lin Gao updated JBJCA-1334: --------------------------- Fix Version/s: WildFly/IronJacamar 1.3.5.Final 1.2.8.Final > Add DataSource to ManagementRepository only after deployed successfully > ----------------------------------------------------------------------- > > Key: JBJCA-1334 > URL: https://issues.jboss.org/browse/JBJCA-1334 > Project: IronJacamar > Issue Type: Bug > Components: Deployer > Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final > Reporter: Lin Gao > Assignee: Lin Gao > Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final > > > When a data-source was failed to be added either because of missing connection-properties: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2) > {code} > or missing of connection-url: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2) > {code} > , it can be added by correcting the information, like: > {code:} > [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test") > {"outcome" => "success"} > {code} > But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1334) Add DataSource to ManagementRepository only after deployed successfully

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1334?page=com.atlassian.jira.plugin... ] Lin Gao resolved JBJCA-1334. ---------------------------- Resolution: Done > Add DataSource to ManagementRepository only after deployed successfully > ----------------------------------------------------------------------- > > Key: JBJCA-1334 > URL: https://issues.jboss.org/browse/JBJCA-1334 > Project: IronJacamar > Issue Type: Bug > Components: Deployer > Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final > Reporter: Lin Gao > Assignee: Lin Gao > Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final > > > When a data-source was failed to be added either because of missing connection-properties: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2) > {code} > or missing of connection-url: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2) > {code} > , it can be added by correcting the information, like: > {code:} > [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test") > {"outcome" => "success"} > {code} > But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1334) Add DataSource to ManagementRepository only after deployed successfully

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1334?page=com.atlassian.jira.plugin... ] Lin Gao updated JBJCA-1334: --------------------------- Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/581, https://github.com/ironjacamar/ironjacamar/pull/582 (was: https://github.com/ironjacamar/ironjacamar/pull/581) > Add DataSource to ManagementRepository only after deployed successfully > ----------------------------------------------------------------------- > > Key: JBJCA-1334 > URL: https://issues.jboss.org/browse/JBJCA-1334 > Project: IronJacamar > Issue Type: Bug > Components: Deployer > Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final > Reporter: Lin Gao > Assignee: Lin Gao > > When a data-source was failed to be added either because of missing connection-properties: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2) > {code} > or missing of connection-url: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2) > {code} > , it can be added by correcting the information, like: > {code:} > [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test") > {"outcome" => "success"} > {code} > But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1334) Add DataSource to ManagementRepository only after deployed successfully

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1334?page=com.atlassian.jira.plugin... ] Lin Gao updated JBJCA-1334: --------------------------- Affects Version/s: 1.2.7.Final WildFly/IronJacamar 1.3.4.Final > Add DataSource to ManagementRepository only after deployed successfully > ----------------------------------------------------------------------- > > Key: JBJCA-1334 > URL: https://issues.jboss.org/browse/JBJCA-1334 > Project: IronJacamar > Issue Type: Bug > Components: Deployer > Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final > Reporter: Lin Gao > Assignee: Lin Gao > > When a data-source was failed to be added either because of missing connection-properties: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2) > {code} > or missing of connection-url: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2) > {code} > , it can be added by correcting the information, like: > {code:} > [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test") > {"outcome" => "success"} > {code} > But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7178) Review empty-role-decoder resource in Elytron subsystem

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7178?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7178: ---------------------------------- role-decoder is used in RealmRef in SecurityDomain only and it is optional here. (covered by test) I will remove empty-role-decoder. > Review empty-role-decoder resource in Elytron subsystem > ------------------------------------------------------- > > Key: WFLY-7178 > URL: https://issues.jboss.org/browse/WFLY-7178 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > We have an empty-role-decoder resource but it is a bit pointless really as it contains no configuration. > Instead I think all references to role-decoder should be optional and where there is no reference to a role decoder we automatically use the empty implementation instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7178) Review empty-role-decoder resource in Elytron subsystem

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7178?page=com.atlassian.jira.plugin.... ] Jan Kalina updated WFLY-7178: ----------------------------- Description: We have an empty-role-decoder resource but it is a bit pointless really as it contains no configuration. Instead I think all references to role-decoder should be optional and where there is no reference to a role decoder we automatically use the empty implementation instead. was:See description of JBEAP-6100 for more details. > Review empty-role-decoder resource in Elytron subsystem > ------------------------------------------------------- > > Key: WFLY-7178 > URL: https://issues.jboss.org/browse/WFLY-7178 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > > We have an empty-role-decoder resource but it is a bit pointless really as it contains no configuration. > Instead I think all references to role-decoder should be optional and where there is no reference to a role decoder we automatically use the empty implementation instead. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1334) Add DataSource to ManagementRepository only after deployed successfully

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1334?page=com.atlassian.jira.plugin... ] Lin Gao commented on JBJCA-1334: -------------------------------- PR is up: https://github.com/ironjacamar/ironjacamar/pull/581 > Add DataSource to ManagementRepository only after deployed successfully > ----------------------------------------------------------------------- > > Key: JBJCA-1334 > URL: https://issues.jboss.org/browse/JBJCA-1334 > Project: IronJacamar > Issue Type: Bug > Components: Deployer > Reporter: Lin Gao > Assignee: Lin Gao > > When a data-source was failed to be added either because of missing connection-properties: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2) > {code} > or missing of connection-url: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2) > {code} > , it can be added by correcting the information, like: > {code:} > [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test") > {"outcome" => "success"} > {code} > But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1334) Add DataSource to ManagementRepository only after deployed successfully

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1334?page=com.atlassian.jira.plugin... ] Lin Gao updated JBJCA-1334: --------------------------- Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/581 > Add DataSource to ManagementRepository only after deployed successfully > ----------------------------------------------------------------------- > > Key: JBJCA-1334 > URL: https://issues.jboss.org/browse/JBJCA-1334 > Project: IronJacamar > Issue Type: Bug > Components: Deployer > Reporter: Lin Gao > Assignee: Lin Gao > > When a data-source was failed to be added either because of missing connection-properties: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2) > {code} > or missing of connection-url: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2) > {code} > , it can be added by correcting the information, like: > {code:} > [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test") > {"outcome" => "success"} > {code} > But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1334) Add DataSource to ManagementRepository only after deployed successfully

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1334?page=com.atlassian.jira.plugin... ] Lin Gao reassigned JBJCA-1334: ------------------------------ Assignee: Lin Gao (was: Jesper Pedersen) > Add DataSource to ManagementRepository only after deployed successfully > ----------------------------------------------------------------------- > > Key: JBJCA-1334 > URL: https://issues.jboss.org/browse/JBJCA-1334 > Project: IronJacamar > Issue Type: Bug > Components: Deployer > Reporter: Lin Gao > Assignee: Lin Gao > > When a data-source was failed to be added either because of missing connection-properties: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2) > {code} > or missing of connection-url: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2) > {code} > , it can be added by correcting the information, like: > {code:} > [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test") > {"outcome" => "success"} > {code} > But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1334) Add DataSource to ManagementRepository only after deployed successfully

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1334?page=com.atlassian.jira.plugin... ] Lin Gao edited comment on JBJCA-1334 at 9/29/16 4:09 AM: --------------------------------------------------------- This Jira is created by cloning the WFLY-7214. The reason for the problem is that {{AbstractDsDeployer}} [added the DataSource into ManagementRepository|https://github.com/ironjacamar/ironjacamar/blob/1.3/...] before it knows that the DataSource deployment will succeed. Move the addition a little late will solve the problem. {{test-connection-in-pool()}} operation in WildFly CLI tries to match the DataSource by iterating DataSouces in the ManagementRepository. Left the failed DataSource in the ManagementRepository is an error tone, so we need to clear it in case of exceptions. was (Author: gaol): This Jira is created by cloning the WFLY-7214. The reason for the problem is that {{AbstractDsDeployer}} [added the DataSource into ManagementRepository|https://github.com/ironjacamar/ironjacamar/blob/1.3/...] before it knows that the DataSource deployment will succeed. Move the addition a little late will solve the problem. > Add DataSource to ManagementRepository only after deployed successfully > ----------------------------------------------------------------------- > > Key: JBJCA-1334 > URL: https://issues.jboss.org/browse/JBJCA-1334 > Project: IronJacamar > Issue Type: Bug > Components: Deployer > Reporter: Lin Gao > Assignee: Jesper Pedersen > > When a data-source was failed to be added either because of missing connection-properties: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, datasource-class=XXX,driver-name=h2) > {code} > or missing of connection-url: > {code:} > /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2) > {code} > , it can be added by correcting the information, like: > {code:} > [standalone@localhost:9990 /] /subsystem=datasources/data-source=XXX:add(jndi-name=java:/XXX, driver-name=h2,connection-url="jdbc:h2:test") > {"outcome" => "success"} > {code} > But the {{test-connection-in-pool()}} operation failed with {{IllegalStateException}} of the new created data-source. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 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 September 2016