[JBoss JIRA] (WFCORE-1752) The deployment-overlay command fails to redeploy affected deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1752?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1752:
------------------------------------------
And for myself. :) It was kind of a brainstorming question. A deployment-overlay resource could certainly have a "redeploy-affected" operation where it works out the set of affected deployments and adds steps to redeploy them. The full set of deployments, their runtime names, and their enabled status would all be available to the handler for such an operation.
I generally don't like adding lots of server-side operations that are just convenience ops for things the client could do. That leads to a cluttered API and might make it harder to evolve the server later without breaking compatibility. But in this case we may have to, since it seems this isn't something the client really can't do in a reasonable manner.
> The deployment-overlay command fails to redeploy affected deployments
> ---------------------------------------------------------------------
>
> Key: WFCORE-1752
> URL: https://issues.jboss.org/browse/WFCORE-1752
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 3.0.0.Alpha5
> Reporter: ehsavoie Hugonnet
> Assignee: Jean-Francois Denise
>
> The deployment-overlay command fails to redeploy affected deployments if the runtime-name isn't the same as the deployment name. Since affected deployment to be redeployed should be running the couple runtime-name + enabled == true should be used to define which deployments are affected instead of using the deployment name since the name used in overlay is the runtime-name
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (WFLY-7342) Updating of elytron kerberos security factory requires reload
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7342?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev reassigned WFLY-7342:
-----------------------------------
Assignee: Darran Lofthouse (was: Ilia Vassilev)
> Updating of elytron kerberos security factory requires reload
> -------------------------------------------------------------
>
> Key: WFLY-7342
> URL: https://issues.jboss.org/browse/WFLY-7342
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> Is it necessary? I mean adding kerberos-security-factory does not require reload.
> It relates to all of attributes debug, minimum-remaining-lifetime principal, request-lifetime,
> mechanism-oids, path, relative-to, server. For example
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (WFLY-7886) Remove ASM (and few other unneeded dependencies) from JPA module as its no longer needed
by Scott Marlow (JIRA)
Scott Marlow created WFLY-7886:
----------------------------------
Summary: Remove ASM (and few other unneeded dependencies) from JPA module as its no longer needed
Key: WFLY-7886
URL: https://issues.jboss.org/browse/WFLY-7886
Project: WildFly
Issue Type: Task
Components: JPA / Hibernate
Affects Versions: 10.0.0.CR4
Reporter: Scott Marlow
Assignee: Scott Marlow
Fix For: 11.0.0.Alpha1
cglib was removed (see [http://in.relation.to/2010/08/19/deprecated-cglib-support]) from Hibernate, so we no longer the <module name="asm.asm"/> dependency in:
{quote}
modules/system/layers/base/org/hibernate/jipijapa-hibernate5/main/module.xml
modules/system/layers/base/org/hibernate/4.1/module.xml
modules/system/layers/base/org/hibernate/jipijapa-hibernate4-3/main/module.xml
modules/system/layers/base/org/hibernate/4.3/module.xml
modules/system/layers/base/org/hibernate/main/module.xml
{quote}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (WFLY-7342) Updating of elytron kerberos security factory requires reload
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7342?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev reassigned WFLY-7342:
-----------------------------------
Assignee: Ilia Vassilev (was: Darran Lofthouse)
> Updating of elytron kerberos security factory requires reload
> -------------------------------------------------------------
>
> Key: WFLY-7342
> URL: https://issues.jboss.org/browse/WFLY-7342
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
> Labels: user_experience
>
> Is it necessary? I mean adding kerberos-security-factory does not require reload.
> It relates to all of attributes debug, minimum-remaining-lifetime principal, request-lifetime,
> mechanism-oids, path, relative-to, server. For example
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (WFLY-7342) Updating of elytron kerberos security factory requires reload
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7342?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev edited comment on WFLY-7342 at 1/13/17 9:56 AM:
--------------------------------------------------------------
Will close the PR [1] since we need different implementation (see Darran's comment in PR [1] and JBEAP-6490).
[~dlofthouse] I'm assigning this issue to you since you recently took JBEAP-6490.
[1] https://github.com/wildfly-security/elytron-subsystem/pull/274
was (Author: ivassile):
Will close the PR [1] since we need a different implementation (see Darran's comment in PR [1] and JBEAP-6490).
[~dlofthouse] I'm assigning this issue to you since you recently took JBEAP-6490.
[1] https://github.com/wildfly-security/elytron-subsystem/pull/274
> Updating of elytron kerberos security factory requires reload
> -------------------------------------------------------------
>
> Key: WFLY-7342
> URL: https://issues.jboss.org/browse/WFLY-7342
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> Is it necessary? I mean adding kerberos-security-factory does not require reload.
> It relates to all of attributes debug, minimum-remaining-lifetime principal, request-lifetime,
> mechanism-oids, path, relative-to, server. For example
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (DROOLS-1405) Drools compiler throws NPE on DRL save when more than one rule extends same rule in the same package
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1405?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1405.
---------------------------------
Resolution: Cannot Reproduce Bug
I cannot reproduce the problem with drools-compiler. The following test case works for me:
{code}
@Test
public void test() {
// DROOLS-1405
String drl1 =
"rule \"test1\" when then end\n";
String drl2 =
"rule \"test2\" extends \"test1\" when then end\n" +
"rule \"test3\" extends \"test1\" when then end\n";
KieSession kieSession = new KieHelper().addContent( drl1, ResourceType.DRL )
.addContent( drl2, ResourceType.DRL )
.build().newKieSession();
}
{code}
In case you can write a test case reproducing this problem please provide it and feel free to reopen this ticket.
> Drools compiler throws NPE on DRL save when more than one rule extends same rule in the same package
> ----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1405
> URL: https://issues.jboss.org/browse/DROOLS-1405
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.5.0.Final, 7.0.0.Beta5
> Environment: Linux - CentOS 6.8
> wildfly 10.0.1
> kie 6.5.x and 7 snapshot
> Reporter: Gal Nitzan
> Assignee: Mario Fusco
> Priority: Critical
> Labels: NPE, drl, drools
>
> Hi,
> I get the following error when saving a DRL file:
> 2017-01-12 23:16:39,677 INFO [org.guvnor.common.services.builder.ResourceChangeIncrementalBuilder] (EJB default - 10) Incremental build request being processed: default://master@opsc/health/src/main/resources/com/opsc/health/test2.drl (updated).
> 2017-01-12 23:16:39,730 ERROR [org.kie.workbench.common.services.backend.builder.Builder] (EJB default - 10) null: java.lang.NullPointerException
> at java.util.LinkedList.addAll(LinkedList.java:408)
> at java.util.LinkedList.addAll(LinkedList.java:387)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.sortRulesByDependency(KnowledgeBuilderImpl.java:1231)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:1086)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:989)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildRules(CompositeKnowledgeBuilderImpl.java:264)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:122)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:105)
> at org.drools.compiler.kie.builder.impl.KieBuilderSetImpl.buildChanges(KieBuilderSetImpl.java:142)
> at org.drools.compiler.kie.builder.impl.KieBuilderSetImpl.build(KieBuilderSetImpl.java:94)
> at org.kie.workbench.common.services.backend.builder.Builder.buildIncrementally(Builder.java:539)
> at org.kie.workbench.common.services.backend.builder.Builder.addResource(Builder.java:383)
> at org.kie.workbench.common.services.backend.builder.Builder.addResource(Builder.java:324)
> at org.kie.workbench.common.services.backend.builder.Builder.updateResource(Builder.java:405)
> at org.kie.workbench.common.services.backend.builder.BuildServiceImpl.lambda$updatePackageResource$1(BuildServiceImpl.java:320)
> at org.kie.workbench.common.services.backend.builder.BuildServiceImpl.updatePackageResource(BuildServiceImpl.java:338)
> at org.kie.workbench.common.services.backend.builder.BuildServiceImpl.updatePackageResource(BuildServiceImpl.java:319)
> at org.kie.workbench.common.services.backend.builder.BuildServiceImpl$Proxy$_$$_WeldClientProxy.updatePackageResource(Unknown Source)
> at org.guvnor.common.services.builder.ResourceChangeIncrementalBuilder$4.execute(ResourceChangeIncrementalBuilder.java:267)
> at org.guvnor.common.services.builder.IncrementalBuilderExecutorManager.execute(IncrementalBuilderExecutorManager.java:77)
> at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:313)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:237)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LogDiagnosticContextRecoveryInterceptor.processInvocation(LogDiagnosticContextRecoveryInterceptor.java:82)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AsyncFutureInterceptorFactory$1$2.runInvocation(AsyncFutureInterceptorFactory.java:104)
> at org.jboss.as.ejb3.component.interceptors.AsyncInvocationTask.run(AsyncInvocationTask.java:74)
> 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)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (WFLY-7342) Updating of elytron kerberos security factory requires reload
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7342?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev reassigned WFLY-7342:
-----------------------------------
Assignee: Darran Lofthouse (was: Ilia Vassilev)
> Updating of elytron kerberos security factory requires reload
> -------------------------------------------------------------
>
> Key: WFLY-7342
> URL: https://issues.jboss.org/browse/WFLY-7342
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> Is it necessary? I mean adding kerberos-security-factory does not require reload.
> It relates to all of attributes debug, minimum-remaining-lifetime principal, request-lifetime,
> mechanism-oids, path, relative-to, server. For example
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (WFLY-7342) Updating of elytron kerberos security factory requires reload
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7342?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev commented on WFLY-7342:
-------------------------------------
Will close the PR [1] since we need a different implementation (see Darran's comment in PR [1] and JBEAP-6490).
[~dlofthouse] I'm assigning this issue to you since you recently took JBEAP-6490.
[1] https://github.com/wildfly-security/elytron-subsystem/pull/274
> Updating of elytron kerberos security factory requires reload
> -------------------------------------------------------------
>
> Key: WFLY-7342
> URL: https://issues.jboss.org/browse/WFLY-7342
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
> Labels: user_experience
>
> Is it necessary? I mean adding kerberos-security-factory does not require reload.
> It relates to all of attributes debug, minimum-remaining-lifetime principal, request-lifetime,
> mechanism-oids, path, relative-to, server. For example
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/kerberos-security-factory=krbSF:write-attribute(name=debug, value=true)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months
[JBoss JIRA] (ELY-873) AuthenticationClient testing without jboss-modules
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-873:
------------------------------------
Summary: AuthenticationClient testing without jboss-modules
Key: ELY-873
URL: https://issues.jboss.org/browse/ELY-873
Project: WildFly Elytron
Issue Type: Enhancement
Components: Authentication Client, Testsuite
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta20
Keeping AuthenticationClient usable without a dependency on JBoss Modules is the kind of thing that will be easy to break.
We should probably have a matrix of tests verifying AuthenticationClient anyway, we should then repeat the tests without JBoss Modules on the ClassPath.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 6 months