[JBoss JIRA] (WFCORE-1868) wrong parse of double quote in `\\"`
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1868?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1868:
----------------------------------------------
Hi Brian,
it doesn't seem that Jira sets my name as the default assignee for CLI
issues. Any action on my side?
JF.
> wrong parse of double quote in `\\"`
> -------------------------------------
>
> Key: WFCORE-1868
> URL: https://issues.jboss.org/browse/WFCORE-1868
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: JBoss EAP 7.0.0
> Reporter: Hisanobu Okuda
> Assignee: Jean-Francois Denise
>
> jboss-cli does not parse command line if command line contains {code}\\"{code}
> When a command is
> {code}/system-property=foo4:add(value="vvv\\"){code}
> it shows the sub-prompt '> ' like:
> {code}
> [standalone@localhost:9990 /] /system-property=foo4:add(value="vvv\\")
> >
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ELY-672) Getting identity by DN in Elytron ldap-realm should be case insensitive
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-672?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina moved WFLY-7305 to ELY-672:
--------------------------------------
Project: WildFly Elytron (was: WildFly)
Key: ELY-672 (was: WFLY-7305)
Component/s: Realms
(was: Security)
Affects Version/s: (was: 11.0.0.Alpha1)
> Getting identity by DN in Elytron ldap-realm should be case insensitive
> -----------------------------------------------------------------------
>
> Key: ELY-672
> URL: https://issues.jboss.org/browse/ELY-672
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Realms
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
>
> Elytron ldap-realm allows to use DN as username (e.g. full {{uid=jduke,ou=People,dc=jboss,dc=org}} can be used instead of {{jduke}}). However implementation requires that used DN must start with rdn-identifier in the same case sensitivity as is used in server configuration. Otherwise authentication fails. It means when server configuration uses {{rdn-identifier=uid}} then only {{uid=jduke,...}} can be correctly used, {{UID=jduke,...}} will fail.
> LDAP specification does not talk about case sensitivity of attributes, but most of LDAP servers work with attributes as case insensitive.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-7330) Colocated HA topology with HTTP connectors/acceptors
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7330?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-6466 to WFLY-7330:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7330 (was: JBEAP-6466)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: JMS)
Affects Version/s: 10.1.0.Final
(was: 7.0.0.GA)
> Colocated HA topology with HTTP connectors/acceptors
> ----------------------------------------------------
>
> Key: WFLY-7330
> URL: https://issues.jboss.org/browse/WFLY-7330
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Critical
>
> I try to configure colocated HA topology with HTTP connectors/acceptors but something goes wrong and I see repeated WARN message \[1\] on the first node and on the second I see the \[2\]. Maybe it is misconfiguration, but I have no idea what I do wrong. I attached XML configurations of both nodes, please review it.
> \[1\]
> {code}
> 12:55:47,789 WARN [org.apache.activemq.artemis.core.client] (Thread-10 (ActiveMQ-client-global-threads-487873773)) AMQ212006: Waiting 2 000 milliseconds before next retry. RetryInterval=2 000 and multiplier=1
> {code}
> \[2\]
> {code}
> 12:56:39,054 WARN [org.apache.activemq.artemis.core.client] (Thread-10 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@4766f9b3-516179796)) AMQ212006: Waiting 500 milliseconds before next retry. RetryInterval=500 and multiplier=1
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1845) Logging subsystem scans the CWD on server boot
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1845?page=com.atlassian.jira.plugi... ]
Heiko Braun commented on WFCORE-1845:
-------------------------------------
[~jamezp] Can yo give me an estimate for this? I have a bunch of other WF Core fixes and wonder if it's worth waiting for this.
> Logging subsystem scans the CWD on server boot
> ----------------------------------------------
>
> Key: WFCORE-1845
> URL: https://issues.jboss.org/browse/WFCORE-1845
> Project: WildFly Core
> Issue Type: Bug
> 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, 6 months
[JBoss JIRA] (WFLY-5213) Injecting external context to Artemis fails
by Ondřej Kalman (JIRA)
[ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.... ]
Ondřej Kalman edited comment on WFLY-5213 at 10/18/16 3:21 AM:
---------------------------------------------------------------
Hi, [~drzeyan] messaging subsystem should contain 2 things, remote connector and pooled-connection-factories which will use it. You don't have to add any other extension to the config.
Then you have to define external-context in naming subsystem pointing to the remote artemis broker. You should keep in mind that standalone artemis uses different naming conventions of queues and topics than WildFly/EAP does. You can do workaround (if you want) in naming subsystem to eliminate this problem, here is an example.
{code:java}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
<bindings>
<external-context name="java:global/remoteContext" module="org.apache.activemq.artemis" class="javax.naming.InitialContext">
<environment>
<property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
<property name="java.naming.provider.url" value="tcp://127.0.0.1:61616"/>
<property name="queue.MDB_QUEUE" value="MDB_QUEUE"/>
</environment>
</external-context>
<lookup name="java:/MDB_QUEUE" lookup="java:global/remoteContext/MDB_QUEUE"/>
</bindings>
</subsystem>
{code}
was (Author: okalman):
Hi, [~drzeyan] messaging subsystem should contain 2 things, remote connector and pooled-connection-factories which will use it. You don't have to add any other extension to the config.
Then you have to define external-context in naming subsystem pointing to the remote artemis broker. You should keep in mind that standalone artemis uses different naming conventions of queues and topics than EAP does. You can do workaround (if you want) in naming subsystem to eliminate this problem, here is an example.
{code:java}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
<bindings>
<external-context name="java:global/remoteContext" module="org.apache.activemq.artemis" class="javax.naming.InitialContext">
<environment>
<property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
<property name="java.naming.provider.url" value="tcp://127.0.0.1:61616"/>
<property name="queue.MDB_QUEUE" value="MDB_QUEUE"/>
</environment>
</external-context>
<lookup name="java:/MDB_QUEUE" lookup="java:global/remoteContext/MDB_QUEUE"/>
</bindings>
</subsystem>
{code}
> Injecting external context to Artemis fails
> -------------------------------------------
>
> Key: WFLY-5213
> URL: https://issues.jboss.org/browse/WFLY-5213
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Beta2
> Reporter: Ondřej Kalman
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-5213) Injecting external context to Artemis fails
by Ondřej Kalman (JIRA)
[ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.... ]
Ondřej Kalman edited comment on WFLY-5213 at 10/18/16 3:20 AM:
---------------------------------------------------------------
Hi, [~drzeyan] messaging subsystem should contain 2 things, remote connector and pooled-connection-factories which will use it. You don't have to add any other extension to the config.
Then you have to define external-context in naming subsystem pointing to the remote artemis broker. You should keep in mind that standalone artemis uses different naming conventions of queues and topics than EAP does. You can do workaround (if you want) in naming subsystem to eliminate this problem, here is an example.
{code:java}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
<bindings>
<external-context name="java:global/remoteContext" module="org.apache.activemq.artemis" class="javax.naming.InitialContext">
<environment>
<property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
<property name="java.naming.provider.url" value="tcp://127.0.0.1:61616"/>
<property name="queue.MDB_QUEUE" value="MDB_QUEUE"/>
</environment>
</external-context>
<lookup name="java:/MDB_QUEUE" lookup="java:global/remoteContext/MDB_QUEUE"/>
</bindings>
</subsystem>
{code}
was (Author: okalman):
Hi, [~drzeyan] messaging subsystem should contain 2 things, remote connector and pooled-connection-factories which will use it. You don't have to add any other extension to the config.
Then you have to define external-context in naming subsystem pointing to the remote artemis broker. You should keep in mind that standalone artemis uses different naming conventions of queues and topics than EAP does. You can do workaround (if you want) in naming subsystem to eliminate this problem, here is an example.
{code:java}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
<bindings>
<external-context name="java:global/remoteContext" module="org.apache.activemq.artemis" class="javax.naming.InitialContext">
<environment>
<property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
<property name="java.naming.provider.url" value="tcp://127.0.0.1:61616"/>
<property name="queue.testQueue" value="testQueue"/>
</environment>
<property name="queue.MDB_QUEUE" value="MDB_QUEUE"/>
</external-context>
<lookup name="java:/MDB_QUEUE" lookup="java:global/remoteContext/MDB_QUEUE"/>
</bindings>
</subsystem>
{code}
> Injecting external context to Artemis fails
> -------------------------------------------
>
> Key: WFLY-5213
> URL: https://issues.jboss.org/browse/WFLY-5213
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Beta2
> Reporter: Ondřej Kalman
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-5213) Injecting external context to Artemis fails
by Ondřej Kalman (JIRA)
[ https://issues.jboss.org/browse/WFLY-5213?page=com.atlassian.jira.plugin.... ]
Ondřej Kalman commented on WFLY-5213:
-------------------------------------
Hi, [~drzeyan] messaging subsystem should contain 2 things, remote connector and pooled-connection-factories which will use it. You don't have to add any other extension to the config.
Then you have to define external-context in naming subsystem pointing to the remote artemis broker. You should keep in mind that standalone artemis uses different naming conventions of queues and topics than EAP does. You can do workaround (if you want) in naming subsystem to eliminate this problem, here is an example.
{code:java}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
<bindings>
<external-context name="java:global/remoteContext" module="org.apache.activemq.artemis" class="javax.naming.InitialContext">
<environment>
<property name="java.naming.factory.initial" value="org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory"/>
<property name="java.naming.provider.url" value="tcp://127.0.0.1:61616"/>
<property name="queue.testQueue" value="testQueue"/>
</environment>
<property name="queue.MDB_QUEUE" value="MDB_QUEUE"/>
</external-context>
<lookup name="java:/MDB_QUEUE" lookup="java:global/remoteContext/MDB_QUEUE"/>
</bindings>
</subsystem>
{code}
> Injecting external context to Artemis fails
> -------------------------------------------
>
> Key: WFLY-5213
> URL: https://issues.jboss.org/browse/WFLY-5213
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Beta2
> Reporter: Ondřej Kalman
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.CR1
>
>
> When external-context is defined in EAP and it's pointing to external Artemis broker, it can't be injected in to MDB via @Resource(lookup = "java:global/externalcontext"). Such injection results in null object.
> Injecting destinations from external context results in javax.ejb.EJBTransactionRolledbackException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months