[JBoss JIRA] (WFCORE-3053) Regression: disabling/enabling user through add-user script removes all disabled users
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3053?page=com.atlassian.jira.plugi... ]
Ondrej Lukas updated WFCORE-3053:
---------------------------------
Description:
add-user script provides ability to enable/disable existing user. It uses commented lines with users as disabled user, e.g.:
{code}
#admin=2a0923285184943425d1f53ddd58ec7a
{code}
In case when any user is enabled/disabled through add-user script then all other disabled users are removed from given properties file.
was:
add-user script provides ability to enable/disable existing user. It uses commented lines with users as disabled user, e.g.:
{code}
#admin=2a0923285184943425d1f53ddd58ec7a
{code}
In case when any user is enabled/disabled through add-user script then all other disabled users are removed from given properties file.
It is regression against EAP 7.0.0.GA where disabling user does not cause removing another disabled users. For that reason we request blocker flag.
> Regression: disabling/enabling user through add-user script removes all disabled users
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-3053
> URL: https://issues.jboss.org/browse/WFCORE-3053
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts, Security
> Reporter: Ondrej Lukas
> Assignee: Tomaz Cerar
> Priority: Blocker
>
> add-user script provides ability to enable/disable existing user. It uses commented lines with users as disabled user, e.g.:
> {code}
> #admin=2a0923285184943425d1f53ddd58ec7a
> {code}
> In case when any user is enabled/disabled through add-user script then all other disabled users are removed from given properties file.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-3053) Regression: disabling/enabling user through add-user script removes all disabled users
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFCORE-3053:
------------------------------------
Summary: Regression: disabling/enabling user through add-user script removes all disabled users
Key: WFCORE-3053
URL: https://issues.jboss.org/browse/WFCORE-3053
Project: WildFly Core
Issue Type: Bug
Components: Scripts, Security
Reporter: Ondrej Lukas
Assignee: Tomaz Cerar
Priority: Blocker
add-user script provides ability to enable/disable existing user. It uses commented lines with users as disabled user, e.g.:
{code}
#admin=2a0923285184943425d1f53ddd58ec7a
{code}
In case when any user is enabled/disabled through add-user script then all other disabled users are removed from given properties file.
It is regression against EAP 7.0.0.GA where disabling user does not cause removing another disabled users. For that reason we request blocker flag.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-9063) TxException*TestCase fail with security manager
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-9063?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek moved JBEAP-12005 to WFLY-9063:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9063 (was: JBEAP-12005)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EJB
Test Suite
Transactions
(was: EJB)
(was: Test Suite)
(was: Transactions)
Affects Version/s: 11.0.0.Beta1
(was: 7.1.0.ER2)
> TxException*TestCase fail with security manager
> -----------------------------------------------
>
> Key: WFLY-9063
> URL: https://issues.jboss.org/browse/WFLY-9063
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Test Suite, Transactions
> Affects Versions: 11.0.0.Beta1
> Reporter: Ondrej Kotek
> Labels: security-manager
> Attachments: TxExceptionEjbClientTestCase-output.txt, TxExceptionTestCase-output.txt
>
>
> {{TxException*TestCase}} fail with security manager because of missing permission "("java.lang.RuntimePermission" "accessDeclaredMembers")":
> {noformat}
> ERROR [org.jboss.as.ejb3.invocation] (default task-9) WFLYEJB0034: EJB Invocation failed on component CmtEjb3 for method public abstract void org.jboss.as.test.integration.ejb.transaction.exception.bean.TestBean.throwExceptionFromTm(org.jboss.as.test.integration.ejb.transaction.exception.TestConfig$TxManagerException) throws java.lang.Exception: javax.ejb.EJBTransactionRolledbackException: WFLYEJB0457: Unexpected Error
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:154)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:257)
> ...
> Caused by: java.lang.ExceptionInInitializerError
> at org.jboss.as.test.integration.ejb.transaction.exception.TestXAResource.createXATestExceptionClass(TestXAResource.java:164)
> at org.jboss.as.test.integration.ejb.transaction.exception.TestXAResource.createDriverSpecificXAException(TestXAResource.java:144)
> ...
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "accessDeclaredMembers")" in code source "(vfs:/content/tx-exception-test.ear/ejb.jar <no signer certificates>)" of "ModuleClassLoader for Module "deployment.tx-exception-test.ear.ejb.jar" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Class.checkMemberAccess(Class.java:2348)
> ...
> {noformat}
> After adding the permission, there are some issues with javassist, see attached logs.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-7896) CME and NPE in Artemis integration seen in test run
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7896?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-7896.
-------------------------------
Fix Version/s: 11.0.0.Alpha1
Resolution: Done
> CME and NPE in Artemis integration seen in test run
> ---------------------------------------------------
>
> Key: WFLY-7896
> URL: https://issues.jboss.org/browse/WFLY-7896
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: David Lloyd
> Assignee: Jeff Mesnil
> Fix For: 11.0.0.Alpha1
>
>
> The exception of note was:
> {noformat}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 64) MSC000001: Failed to start service jboss.messaging-activemq.default.jms.manager: org.jboss.msc.service.StartException in service jboss.messaging-activemq.default.jms.manager: WFLYMSGAMQ0033: Failed to start service
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:203)
> at org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:63)
> at org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:97)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.util.ConcurrentModificationException
> at java.util.Hashtable$Enumerator.next(Hashtable.java:1367)
> at org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.parseSystemProperties(ConfigurationImpl.java:308)
> at org.apache.activemq.artemis.core.config.impl.ConfigurationImpl.parseSystemProperties(ConfigurationImpl.java:299)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:488)
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:466)
> at org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:412)
> at org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:199)
> ... 8 more
> {noformat}
> The build was https://ci.wildfly.org/viewLog.html?buildTypeId=WildFlyProject_Elytron_Wi... which is a topic branch for Elytron integration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8049) Update Artemis SQL statements
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8049?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-8049.
-------------------------------
Fix Version/s: 11.0.0.Alpha1
Resolution: Done
> Update Artemis SQL statements
> ------------------------------
>
> Key: WFLY-8049
> URL: https://issues.jboss.org/browse/WFLY-8049
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 11.0.0.Beta1, 11.0.0.Alpha1
>
>
> After ARTEMIS-938, SQL statements for Artemis JDBC store uses BIGINT for ids instead of INT.
> The SQL statement used by WildFly (in modules/system/layers/base/org/wildfly/extension/messaging-activemq/main/database/journal-sql.properties) must be updated to also use BIGINT
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-8942) Request Scope is not active during Batchlet
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-8942?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-8942:
------------------------------------
[~jamezp] Yep, if you execute a batchlet in a different thread you need to *activate* the request context manually using Weld API, see also http://weld.cdi-spec.org/documentation/#0 and http://docs.jboss.org/weld/reference/latest/en-US/html/contexts.html. However, you cannot propagate the request context bound to an HTTP request. There is an example of using {{BoundRequestContext}} and an external data store. You could even use {{@Inject @Unbound RequestContext}} and store the beans in a thread local (see for example https://github.com/weld/core/blob/2.4/impl/src/main/java/org/jboss/weld/c...). It depends on your requirements.
It seems the Batch spec is DI technology agnostic, i.e. the active scopes are not defined. It's probably a good idea to activate the request context during execution of batch components. However, I'm no batch expert and so I'm not sure about the boundaries (batchlet execution, etc.).
> Request Scope is not active during Batchlet
> -------------------------------------------
>
> Key: WFLY-8942
> URL: https://issues.jboss.org/browse/WFLY-8942
> Project: WildFly
> Issue Type: Bug
> Components: Batch, CDI / Weld
> Affects Versions: 10.1.0.Final
> Environment: Wildfly 10.1.0 Final
> Reporter: Cody Lerum
> Assignee: James Perkins
> Attachments: batch-chunk.war
>
>
> When executing a Java EE 7 batchlet if an injection of an @RequestScoped bean is attempted.
> Example
> {noformat}
> 20:57:13,995 WARN [org.jberet] (Batch Thread - 13) JBERET000001: Failed to run batchlet org.jberet.job.model.RefArtifact@b5b6a97: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
> at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:689)
> at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:90)
> at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:165)
> at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:83)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months