[JBoss JIRA] (WFLY-3149) Windows service on 64 bit systems cannot be stopped
by Rudi Adianto (JIRA)
[ https://issues.jboss.org/browse/WFLY-3149?page=com.atlassian.jira.plugin.... ]
Rudi Adianto commented on WFLY-3149:
------------------------------------
Setting JAVA_HOME in jboss-cli.bat solved this for me.
This seems to hit systems with multiple version of Java.
> Windows service on 64 bit systems cannot be stopped
> ---------------------------------------------------
>
> Key: WFLY-3149
> URL: https://issues.jboss.org/browse/WFLY-3149
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 8.0.0.Final
> Environment: Windows 2008 Server, Windows 7 professional - both 64 bit systems using JDK 1.7.0_09
> Reporter: Mohan Potturi
> Assignee: Mladen Turk
>
> The Windows service cannot be stopped. It says 'stopping' in the windows service user interface window. The only way to stop it is ti actually kill the java process. It works flawlessly on 32 bit systems though.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-9261) Cluster connection receives a "consumer created" message from the rebooting node but it has no corresponding binding for it locally
by Flavia Rainone (JIRA)
Flavia Rainone created WFLY-9261:
------------------------------------
Summary: Cluster connection receives a "consumer created" message from the rebooting node but it has no corresponding binding for it locally
Key: WFLY-9261
URL: https://issues.jboss.org/browse/WFLY-9261
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Flavia Rainone
Assignee: Martyn Taylor
When rebooting a cluster node that uses singleton cluster mdbs, we get this error message:
{noformat}
2017-07-25 16:08:54,426 ERROR [org.apache.activemq.artemis.core.server] (Thread-3 (ActiveMQ-client-global-threads)) AMQ224037: cluster connection Failed to handle message: java.lang.IllegalStateException: Cannot find binding for jms.queue.HelloWorldMDBQueuedea3e995-713c-11e7-85f2-b8f6b112daf7 on ClusterConnectionImpl@1129705701[nodeUUID=dabaa1fa-713c-11e7-8f3a-b8f6b112daf7, connector=TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEndpoint=http-acceptor&activemqServerName=default&httpUpgradeEnabled=true&port=9080&host=localhost, address=jms, server=ActiveMQServerImpl::serverUUID=dabaa1fa-713c-11e7-8f3a-b8f6b112daf7]
at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.doConsumerCreated(ClusterConnectionImpl.java:1294)
at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.handleNotificationMessage(ClusterConnectionImpl.java:1029)
at org.apache.activemq.artemis.core.server.cluster.impl.ClusterConnectionImpl$MessageFlowRecordImpl.onMessage(ClusterConnectionImpl.java:1004)
at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001)
at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49)
at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124)
at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
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)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1714) Accumulate compile issue with java dialect
by Justin Goldsmith (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1714?page=com.atlassian.jira.plugi... ]
Justin Goldsmith commented on DROOLS-1714:
------------------------------------------
Just tested on 6.5.0.Final-redhat-9 and got the same error, so this seems like it is a BRMS issue too.
> Accumulate compile issue with java dialect
> ------------------------------------------
>
> Key: DROOLS-1714
> URL: https://issues.jboss.org/browse/DROOLS-1714
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.2.0.Final
> Reporter: Justin Goldsmith
> Assignee: Mario Fusco
>
> when using java dialect in a accumulate, if there is a binding in the accumulate to a type that is not imported, you get a class cast error instead of the normal unable to resolve
> "object.java.lang.ClassCastException: org.drools.compiler.rule.builder.dialect.mvel.MVELAnalysisResult cannot be cast to org.drools.compiler.rule.builder.dialect.java.JavaAnalysisResult"
> Please see the following reproducer with three test cases that expect failure.
> 2 of the tests have the expected failure, one does not.
> https://github.com/jgoldsmith613/drools-accumulate-bug
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-9251) Security context is not thread safe
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9251?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-9251:
-----------------------------------
WildFly 11 comes with completly new security layer; elytron,
can you try to reproduce if problem still exist in 11 Beta1? or even nightly builds?
> Security context is not thread safe
> -----------------------------------
>
> Key: WFLY-9251
> URL: https://issues.jboss.org/browse/WFLY-9251
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.1.0.Final
> Environment: Windows, LInux
> Reporter: charles ghislain
> Assignee: Darran Lofthouse
> Labels: jaas, security, security-context, thread-safety, threads
> Attachments: wildflytestauthcontext-2.zip, wildflytestauthcontext.zip
>
>
> Using a custom JAAS login module, we sometimes fail to obtain the authenticated subject from the 'javax.security.auth.Subject.container' policy context. This appear to be related to the worker threads.
> See the reproduction steps below. When a wildfly instance attempts to authenticate 500 requests coming simultaneously, a bunch of them fail. If you configure wildfly to only use a single worker thread and a single task thread, this issue disappears.
> The issue is as follow:
> I login using HttpServletRequest#login.
> Right after that, login.getUserPrincipal return the correct principal.
> However, sometimes, PolicyContext.getContext("javax.security.auth.Subject.container") returns null. Right after the login.
> In our production app, PolicyContext.getContext("javax.security.auth.Subject.container") returns null during some EJB call, throwing random exceptions from various parts of the application.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1714) Accumulate compile issue with java dialect
by Justin Goldsmith (JIRA)
Justin Goldsmith created DROOLS-1714:
----------------------------------------
Summary: Accumulate compile issue with java dialect
Key: DROOLS-1714
URL: https://issues.jboss.org/browse/DROOLS-1714
Project: Drools
Issue Type: Bug
Affects Versions: 7.2.0.Final
Reporter: Justin Goldsmith
Assignee: Edson Tirelli
when using java dialect in a accumulate, if there is a binding in the accumulate to a type that is not imported, you get a class cast error instead of the normal unable to resolve
"object.java.lang.ClassCastException: org.drools.compiler.rule.builder.dialect.mvel.MVELAnalysisResult cannot be cast to org.drools.compiler.rule.builder.dialect.java.JavaAnalysisResult"
Please see the following reproducer with three test cases that expect failure.
2 of the tests have the expected failure, one does not.
https://github.com/jgoldsmith613/drools-accumulate-bug
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ELY-681) Hide private packages from generated javadoc.
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-681?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina reassigned ELY-681:
------------------------------
Assignee: Jan Kalina
> Hide private packages from generated javadoc.
> ---------------------------------------------
>
> Key: ELY-681
> URL: https://issues.jboss.org/browse/ELY-681
> Project: WildFly Elytron
> Issue Type: Task
> Components: Build
> Reporter: Darran Lofthouse
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 1.2.0.Beta3
>
>
> We may want two profiles so we can generate a full javadoc and a 'public' javadoc.
> The 'public' javadoc should be the default one generated and should exclude the following packages: -
> org.wildfly.security._private
> org.wildfly.security.asn1
> org.wildfly.security.auth.realm
> org.wildfly.security.auth.realm.*
> org.wildfly.security.authz.jacc
> org.wildfly.security.credential.store.impl
> org.wildfly.security.security.digest
> org.wildfly.security.http.impl
> org.wildfly.security.security.keystore
> org.wildfly.security.mechanism.oauth2
> org.wildfly.security.mechanism.scram
> org.wildfly.security.password.impl
> org.wildfly.security.password.util
> org.wildfly.security.pem
> org.wildfly.security.sasl
> org.wildfly.security.sasl.* (Except util)
> org.wildfly.security.util
> org.wildfly.security.util_private
> org.wildfly.security.x500
> org.wildfly.security.x500.cert
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months