[JBoss JIRA] (WFLY-6607) Broadcast/Discovery group is possible to create with just a name
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6607?page=com.atlassian.jira.plugin.... ]
Chao Wang reassigned WFLY-6607:
-------------------------------
Assignee: Chao Wang (was: Chen Maoqian)
> Broadcast/Discovery group is possible to create with just a name
> ----------------------------------------------------------------
>
> Key: WFLY-6607
> URL: https://issues.jboss.org/browse/WFLY-6607
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Web Console
> Affects Versions: 10.0.0.Final
> Reporter: Chen Maoqian
> Assignee: Chao Wang
>
> When defining new broadcast-group in Configuration: Subsystems Subsystem: Messaging - ActiveMQ Messaging Provider: default
> user must define name, at least one connector and then either socket-binding or jgroups-channel-name (not both of them, just one)
> At this moment it's possible to create broadcast group with just a name which is wrong.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8329) cannot set await-initial-transfer attribute in infinispan configuration
by Daniele Pirola (JIRA)
Daniele Pirola created WFLY-8329:
------------------------------------
Summary: cannot set await-initial-transfer attribute in infinispan configuration
Key: WFLY-8329
URL: https://issues.jboss.org/browse/WFLY-8329
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.1.0.Final
Reporter: Daniele Pirola
Assignee: Paul Ferraro
Inside wildfly infinispan configuration I can't set attribute {{await-initial-transfer}} even if it's present in Infinispan 8.2.4.Final (see {{org.infinispan.configuration.cache.StateTransferConfiguration}}).
This is the subsystem that doesn't work:
{{<subsystem xmlns="urn:jboss:domain:infinispan:4.0">
<cache-container XXX >
<distributed-cache XXX >
...
<state-transfer await-initial-transfer="true" />
</distributed-cache>}}
There is a workaround to set this attribute at runtime?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (DROOLS-1471) Unable to marshall a kieSession running in stream mode.
by Manjunath S Paramesan (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1471?page=com.atlassian.jira.plugi... ]
Manjunath S Paramesan commented on DROOLS-1471:
-----------------------------------------------
Hi [~mfusco],
Please find the eclipse project to reproduce this issue on GitHub: https://github.com/manjunath-sp/drools-marshaller-tester
Hope this helps.
Thanks,
Manjunath
> Unable to marshall a kieSession running in stream mode.
> -------------------------------------------------------
>
> Key: DROOLS-1471
> URL: https://issues.jboss.org/browse/DROOLS-1471
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Manjunath S Paramesan
> Assignee: Mario Fusco
>
> Runtime exceptions are thrown when Marshalling a KieSession in runtime. Please see the stack trace below:
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at drools.tester.drools.marshallng.tester.ReproducerTest.test(ReproducerTest.java:91)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 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:675)
> 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: java.lang.NullPointerException
> at org.drools.core.util.index.TupleList.removeFirst(TupleList.java:142)
> at org.drools.core.phreak.RuleExecutor.getNextTuple(RuleExecutor.java:167)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:107)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350)
> at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1269)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1345)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1324)
> at drools.tester.drools.marshallng.tester.ReproducerTest$1.run(ReproducerTest.java:73)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-157) Write expressions to logging.properties configuration file
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-157?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFCORE-157:
--------------------------------------
I wouldn't think any. The current default in the {{logging.properties}} is:
{code}
${jboss.server.log.dir}/server.log
{code}
Once the logging subsystem is added the {{logging.properties}} gets rewritten with the fully-qualified path. So it should work the same for IDE's unless they do some kind of tweaking to the {{logging.properties}}.
The idea will be to write the values like:
{code}
handler.FILE.fileName=${jboss.server.log.dir:/home/jperkins/servers/wildfly-10.1.0.Final/standalone/log}/server.log
{code}
The default value will be the last good/known value. But if the property is defined it will use the property value.
> Write expressions to logging.properties configuration file
> ----------------------------------------------------------
>
> Key: WFCORE-157
> URL: https://issues.jboss.org/browse/WFCORE-157
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Optional
>
> Allow properties that use expressions to write the expression out to the logging.properties configuration file. This allows properties passed in at runtime to affect the initial logging configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (SECURITY-956) New behavior for empty string in rolesCtxDN in LdapExtLoginModule in EAP 7.1
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/SECURITY-956?page=com.atlassian.jira.plug... ]
Stefan Guilhen resolved SECURITY-956.
-------------------------------------
Fix Version/s: PicketBox_5_0_0.Beta1
Resolution: Done
> New behavior for empty string in rolesCtxDN in LdapExtLoginModule in EAP 7.1
> ----------------------------------------------------------------------------
>
> Key: SECURITY-956
> URL: https://issues.jboss.org/browse/SECURITY-956
> Project: PicketBox
> Issue Type: Bug
> Affects Versions: PicketBox_5_0_0.Alpha3
> Reporter: Ondrej Lukas
> Assignee: Stefan Guilhen
> Fix For: PicketBox_5_0_0.Beta1
>
>
> In case when LdapExtLoginModule has option rolesCtxDN set to empty string then it has different behavior in EAP 7.0 (PicketBox 4.9.x) and 7.1 (PicketBox 5.0.x).
> EAP 7.0 uses empty string as base search for LDAP.
> * In case when LDAP server supports empty string search base (e.g. Apache DS allows it) it works as expected, all LDAP tree is searched for roles.
> * In case when LDAP server does not support empty string search base (e.g. Active Directory or Red Hat Directory Server) it thrown exception authentication fails. However exception is expected since it is misconfiguration for those LDAP servers.
> EAP 7.1 does not search any roles for empty string. That means:
> * In case when LDAP server supports empty string search base it does not find any roles. However some roles could be found on that type of LDAP servers.
> * In case when LDAP server does not support empty string search base it correctly returns no roles and authentication passes.
> From my PoV, behavior from EAP 7.0 is more correct, because it works correctly for LDAP servers where empty string is legal search base. However it can be decided that current EAP 7.1 behavior is intended. In that case please create Release Notes Jira (because it is change in behavior) and close this Jira.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months