[JBoss JIRA] (WFCORE-1985) :read-resource-description operation should consistently order resources by alphabet
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1985?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1985:
----------------------------------------
Assignee: Ken Wills (was: Brian Stansberry)
> :read-resource-description operation should consistently order resources by alphabet
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-1985
> URL: https://issues.jboss.org/browse/WFCORE-1985
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Michal Jurc
> Assignee: Ken Wills
>
> While {{:read-resource-description}} returns an ordered list of resources with their descriptions for most resources, some resources do not return result consistent with this (resources ordered by alphabet).
> Affected resources:
> * {{/subsystem=iiop-openjdk:read-resource-description()}} returns unordered list of resources and their descriptions, while {{/subsystem=iiop-openjdk:read-resource()}} returns ordered list
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7581) Drop the use of the org.jboss.invocation.PrivilegedWithCombinerInterceptor to be compatible with JBoss Invocation 1.5.0
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7581?page=com.atlassian.jira.plugin.... ]
Farah Juma updated WFLY-7581:
-----------------------------
Summary: Drop the use of the org.jboss.invocation.PrivilegedWithCombinerInterceptor to be compatible with JBoss Invocation 1.5.0 (was: Drop the use of the org.jboss.invocation.PrivilegedWithCombinerInterceptor)
> Drop the use of the org.jboss.invocation.PrivilegedWithCombinerInterceptor to be compatible with JBoss Invocation 1.5.0
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7581
> URL: https://issues.jboss.org/browse/WFLY-7581
> Project: WildFly
> Issue Type: Task
> Components: EE
> Reporter: Farah Juma
> Assignee: Farah Juma
>
> Due to the security implications of PrivilegedInterceptor and PrivilegedWithCombinerInterceptor, these two interceptors were changed to be no-operation a while back. These interceptors have been removed in jboss-invocation 1.5.0.Beta2. PrivilegedWithCombinerInterceptor is still currently being used in WildFly but we should be able to drop the use of this interceptor.
> Relevant HipChat discussion with David:
> {code}
> [3:18 PM] Farah Juma: So far, with the latest jboss-invocation SNAPSHOT, I'm running into many WildFly testsuite failures related to the org.jboss.invocation.PrivilegedWithCombinerInterceptor class not being found
> [3:18 PM] Farah Juma: This class was removed in jboss-invocation 1.5.0.Beta2
> [3:26 PM] Farah Juma: Just wondering what should now be used instead of the PrivilegedWithCombinerInterceptor
> [3:26 PM] David M. Lloyd: hmm that class was actually used?
> [3:27 PM] David M. Lloyd: the class was basically a giant security hole
> [3:28 PM] Farah Juma: it's used in these four classes: DefaultComponentConfigurator, ManagedBeanAnnotationProcessor, EJBComponentDescription, and AbstractIntegrationProcessorJAXWS
> [3:29 PM] David M. Lloyd: I think it's got to be safe to just remove it
> [3:29 PM] David M. Lloyd: because [a] we're not using picketbox anymore, and [b] it was a no-op without a security manager present anyway
> [3:31 PM] Farah Juma: ok, thanks, I'll remove the references to it
> [3:36 PM] David M. Lloyd: to be clear, those doPrivileged interceptors were not specifically to support PB: they were to ensure that applications run with only their own privileges
> [3:37 PM] David M. Lloyd: the combiner part was necessary to propagate Subject, which might still be necessary
> [3:37 PM] David M. Lloyd: but since the privileged part was not, just dropping the interceptors works just fine to propagate Subject (because there's nothing stopping said propagation)
> [3:38 PM] David M. Lloyd: because of the security implications of those two interceptors, they were changed to be no-operation a while ago, so it should be no loss
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7581) Drop the use of the org.jboss.invocation.PrivilegedWithCombinerInterceptor
by Farah Juma (JIRA)
Farah Juma created WFLY-7581:
--------------------------------
Summary: Drop the use of the org.jboss.invocation.PrivilegedWithCombinerInterceptor
Key: WFLY-7581
URL: https://issues.jboss.org/browse/WFLY-7581
Project: WildFly
Issue Type: Task
Components: EE
Reporter: Farah Juma
Assignee: Farah Juma
Due to the security implications of PrivilegedInterceptor and PrivilegedWithCombinerInterceptor, these two interceptors were changed to be no-operation a while back. These interceptors have been removed in jboss-invocation 1.5.0.Beta2. PrivilegedWithCombinerInterceptor is still currently being used in WildFly but we should be able to drop the use of this interceptor.
Relevant HipChat discussion with David:
{code}
[3:18 PM] Farah Juma: So far, with the latest jboss-invocation SNAPSHOT, I'm running into many WildFly testsuite failures related to the org.jboss.invocation.PrivilegedWithCombinerInterceptor class not being found
[3:18 PM] Farah Juma: This class was removed in jboss-invocation 1.5.0.Beta2
[3:26 PM] Farah Juma: Just wondering what should now be used instead of the PrivilegedWithCombinerInterceptor
[3:26 PM] David M. Lloyd: hmm that class was actually used?
[3:27 PM] David M. Lloyd: the class was basically a giant security hole
[3:28 PM] Farah Juma: it's used in these four classes: DefaultComponentConfigurator, ManagedBeanAnnotationProcessor, EJBComponentDescription, and AbstractIntegrationProcessorJAXWS
[3:29 PM] David M. Lloyd: I think it's got to be safe to just remove it
[3:29 PM] David M. Lloyd: because [a] we're not using picketbox anymore, and [b] it was a no-op without a security manager present anyway
[3:31 PM] Farah Juma: ok, thanks, I'll remove the references to it
[3:36 PM] David M. Lloyd: to be clear, those doPrivileged interceptors were not specifically to support PB: they were to ensure that applications run with only their own privileges
[3:37 PM] David M. Lloyd: the combiner part was necessary to propagate Subject, which might still be necessary
[3:37 PM] David M. Lloyd: but since the privileged part was not, just dropping the interceptors works just fine to propagate Subject (because there's nothing stopping said propagation)
[3:38 PM] David M. Lloyd: because of the security implications of those two interceptors, they were changed to be no-operation a while ago, so it should be no loss
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (ELY-755) Add ability for client-side SSL context configuration to include authentication
by David Lloyd (JIRA)
David Lloyd created ELY-755:
-------------------------------
Summary: Add ability for client-side SSL context configuration to include authentication
Key: ELY-755
URL: https://issues.jboss.org/browse/ELY-755
Project: WildFly Elytron
Issue Type: Enhancement
Components: API / SPI, Authentication Client, Passwords, SSL, X.500
Reporter: David Lloyd
One thing that was lost in the switch to separate SSL context configuration was the ability to perform client SSL authentication using certificates or other credentials configured in the authentication client configuration.
There should be a configuration option to replace the key manager for the client SSL context with one which uses the authentication configuration to retrieve, at minimum, certificate credentials. Plus whatever is necessary to forward or set a GSSCredential for Kerberos-based mechanisms.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (DROOLS-1143) Guice error resolving implementation for RepositorySystem in shaded jar for kie-ci 6.3.0.Final with spark streaming (1.6.1)
by Jess Evans (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1143?page=com.atlassian.jira.plugi... ]
Jess Evans commented on DROOLS-1143:
------------------------------------
For future reference, the proper way to resolve this problem when forced to generate an uber jar (e.g. Flink job) is to add the appropriate transformers in the Maven shade configuration so that the multitude of META-INF/** config files are not lost. E.g.:
{quote}<transformer implementation="org.apache.maven.plugins.shade.resource.ComponentsXmlResourceTransformer"/>
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
<transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
<resource>META-INF/sisu/javax.inject.Named</resource>
</transformer>{quote}
> Guice error resolving implementation for RepositorySystem in shaded jar for kie-ci 6.3.0.Final with spark streaming (1.6.1)
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1143
> URL: https://issues.jboss.org/browse/DROOLS-1143
> Project: Drools
> Issue Type: Bug
> Reporter: Lucie Zhao
> Assignee: Mario Fusco
>
> I'm working on a project where I'm trying to integrate drools with spark streaming. I've seen this error on DROOLS-723 where it's reported to have been fixed in 6.2.0.Final but I'm using 6.3.0.Final and it's not working for me. I am able to run a quick test in my eclipse work space without the spark piece and it is working for me.
> here's the stack trace:
> {code}
> 016-04-27 10:22:32,360 WARN [streaming-job-executor-0] Sisu (Logs.java:warn(394)) - Error injecting: org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> com.google.inject.ProvisionException: Guice provision errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> 1 error
> at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:974)
> at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1000)
> at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:84)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:52)
> at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
> at org.eclipse.sisu.plexus.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:133)
> at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108)
> at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
> at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
> at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
> at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
> at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:252)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:246)
> at org.kie.scanner.embedder.PlexusComponentProvider.lookup(PlexusComponentProvider.java:42)
> at org.kie.scanner.embedder.MavenEmbedder.buildMavenExecutionRequest(MavenEmbedder.java:111)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:84)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:75)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:69)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:55)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:49)
> at org.kie.scanner.ArtifactResolver.getResolverFor(ArtifactResolver.java:127)
> at org.kie.scanner.ArtifactResolver.getResolverFor(ArtifactResolver.java:90)
> at org.kie.scanner.KieRepositoryScannerImpl.setKieContainer(KieRepositoryScannerImpl.java:88)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieScanner(KieServicesImpl.java:139)
> at com.emc.ctooil.spark.SparkKafkaDroolsConsumer$4.call(SparkKafkaDroolsConsumer.java:239)
> at com.emc.ctooil.spark.SparkKafkaDroolsConsumer$4.call(SparkKafkaDroolsConsumer.java:1)
> at org.apache.spark.streaming.api.java.JavaDStreamLike$$anonfun$foreachRDD$3.apply(JavaDStreamLike.scala:335)
> at org.apache.spark.streaming.api.java.JavaDStreamLike$$anonfun$foreachRDD$3.apply(JavaDStreamLike.scala:335)
> at org.apache.spark.streaming.dstream.DStream$$anonfun$foreachRDD$1$$anonfun$apply$mcV$sp$3.apply(DStream.scala:661)
> at org.apache.spark.streaming.dstream.DStream$$anonfun$foreachRDD$1$$anonfun$apply$mcV$sp$3.apply(DStream.scala:661)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1$$anonfun$apply$mcV$sp$1.apply$mcV$sp(ForEachDStream.scala:50)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1$$anonfun$apply$mcV$sp$1.apply(ForEachDStream.scala:50)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1$$anonfun$apply$mcV$sp$1.apply(ForEachDStream.scala:50)
> at org.apache.spark.streaming.dstream.DStream.createRDDWithLocalProperties(DStream.scala:426)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1.apply$mcV$sp(ForEachDStream.scala:49)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1.apply(ForEachDStream.scala:49)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1.apply(ForEachDStream.scala:49)
> at scala.util.Try$.apply(Try.scala:161)
> at org.apache.spark.streaming.scheduler.Job.run(Job.scala:39)
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler$$anonfun$run$1.apply$mcV$sp(JobScheduler.scala:224)
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler$$anonfun$run$1.apply(JobScheduler.scala:224)
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler$$anonfun$run$1.apply(JobScheduler.scala:224)
> at scala.util.DynamicVariable.withValue(DynamicVariable.scala:57)
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler.run(JobScheduler.scala:223)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> java.lang.RuntimeException: org.kie.scanner.embedder.MavenEmbedderException: com.google.inject.ProvisionException: Guice provision errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> while locating org.apache.maven.execution.MavenExecutionRequestPopulator
> 1 error
> role: org.apache.maven.execution.MavenExecutionRequestPopulator
> roleHint:
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:57)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:49)
> at org.kie.scanner.ArtifactResolver.getResolverFor(ArtifactResolver.java:127)
> at org.kie.scanner.ArtifactResolver.getResolverFor(ArtifactResolver.java:90)
> at org.kie.scanner.KieRepositoryScannerImpl.setKieContainer(KieRepositoryScannerImpl.java:88)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieScanner(KieServicesImpl.java:139)
> at com.emc.ctooil.spark.SparkKafkaDroolsConsumer$4.call(SparkKafkaDroolsConsumer.java:239)
> at com.emc.ctooil.spark.SparkKafkaDroolsConsumer$4.call(SparkKafkaDroolsConsumer.java:1)
> at org.apache.spark.streaming.api.java.JavaDStreamLike$$anonfun$foreachRDD$3.apply(JavaDStreamLike.scala:335)
> at org.apache.spark.streaming.api.java.JavaDStreamLike$$anonfun$foreachRDD$3.apply(JavaDStreamLike.scala:335)
> at org.apache.spark.streaming.dstream.DStream$$anonfun$foreachRDD$1$$anonfun$apply$mcV$sp$3.apply(DStream.scala:661)
> at org.apache.spark.streaming.dstream.DStream$$anonfun$foreachRDD$1$$anonfun$apply$mcV$sp$3.apply(DStream.scala:661)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1$$anonfun$apply$mcV$sp$1.apply$mcV$sp(ForEachDStream.scala:50)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1$$anonfun$apply$mcV$sp$1.apply(ForEachDStream.scala:50)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1$$anonfun$apply$mcV$sp$1.apply(ForEachDStream.scala:50)
> at org.apache.spark.streaming.dstream.DStream.createRDDWithLocalProperties(DStream.scala:426)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1.apply$mcV$sp(ForEachDStream.scala:49)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1.apply(ForEachDStream.scala:49)
> at org.apache.spark.streaming.dstream.ForEachDStream$$anonfun$1.apply(ForEachDStream.scala:49)
> at scala.util.Try$.apply(Try.scala:161)
> at org.apache.spark.streaming.scheduler.Job.run(Job.scala:39)^C
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler$$anonfun$run$1.apply$mcV$sp(JobScheduler.scala:224)
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler$$anonfun$run$1.apply(JobScheduler.scala:224)
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler$$anonfun$run$1.apply(JobScheduler.scala:224)
> at scala.util.DynamicVariable.withValue(DynamicVariable.scala:57)
> at org.apache.spark.streaming.scheduler.JobScheduler$JobHandler.run(JobScheduler.scala:223)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.kie.scanner.embedder.MavenEmbedderException: com.google.inject.ProvisionException: Guice provision errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> while locating org.apache.maven.execution.MavenExecutionRequestPopulator
> 1 error
> role: org.apache.maven.execution.MavenExecutionRequestPopulator
> roleHint:
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:94)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:75)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:69)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:55)
> ... 28 more
> Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: com.google.inject.ProvisionException: Guice provision errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> while locating org.apache.maven.execution.MavenExecutionRequestPopulator
> 1 error
> role: org.apache.maven.execution.MavenExecutionRequestPopulator
> roleHint:
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:264)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:252)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:246)
> at org.kie.scanner.embedder.PlexusComponentProvider.lookup(PlexusComponentProvider.java:42)
> at org.kie.scanner.embedder.MavenEmbedder.buildMavenExecutionRequest(MavenEmbedder.java:111)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:84)
> ... 31 more
> Caused by: com.google.inject.ProvisionException: Guice provision errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]]
> while locating org.apache.maven.execution.MavenExecutionRequestPopulator
> 1 error
> at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:974)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:260)
> ... 36 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7580) JBeret WildFly extension cannot handle runtime-name
by James Perkins (JIRA)
James Perkins created WFLY-7580:
-----------------------------------
Summary: JBeret WildFly extension cannot handle runtime-name
Key: WFLY-7580
URL: https://issues.jboss.org/browse/WFLY-7580
Project: WildFly
Issue Type: Bug
Components: Batch
Affects Versions: 11.0.0.Alpha1
Environment: Nightly build from 11th of November from here:
https://ci.jboss.org/hudson/job/WildFly-latest-master/lastBuild/
java -version
{noformat}
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
{noformat}
Reporter: Markus Falk
Assignee: James Perkins
A NullPointerException is thrown, when using a runtime-name for a batch job.
Exception
{noformat}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 13) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
("deployment" => "batch-chunk-csv-database.war"),
("subsystem" => "batch-jberet"),
("job" => "myJob")
]): java.lang.NullPointerException
at org.wildfly.extension.batch.jberet.deployment.JobOperationStepHandler.execute(JobOperationStepHandler.java:68)
at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:230)
at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:988)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1364)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:416)
at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:237)
at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:431)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:206)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:237)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:464)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:225)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
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)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7393) Elytron Http status code for missing LoginPermission
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7393?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7393:
--------------------------------
Assignee: Jan Kalina
> Elytron Http status code for missing LoginPermission
> ----------------------------------------------------
>
> Key: WFLY-7393
> URL: https://issues.jboss.org/browse/WFLY-7393
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Optional
>
> Lack of {{LoginPermission}} leads to 401 http code. Which could IMO indicate user can try to login again with different password. However it won't help in this case. I wonder, wouldn't 403 Forbidden be more suitable here? Indicating user authentication passed, but user is missing some permission.
> Setting with low priority as in DR7 in default configuration LoginPermission is added by default.
> David: "I think you may be right @MartinChoma - 401 is called "unauthorized" but really it should say "authentication required" 403 is the correct response for an authorization error"
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (DROOLS-1358) No sorting of the field names in the guided rules.
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1358?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1358:
-------------------------------------
Assignee: Michael Anstis (was: Edson Tirelli)
> No sorting of the field names in the guided rules.
> --------------------------------------------------
>
> Key: DROOLS-1358
> URL: https://issues.jboss.org/browse/DROOLS-1358
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Reporter: Petr Farmakovsky
> Assignee: Michael Anstis
> Attachments: Field names.gif
>
>
> We use the Drools Workbench 6.3.0 Final. Our Data Object may consist of more than 20 fields. When writing rules, such as Guided Rules and when adding the object into the rule all fields are displayed unsorted: !Field names.gif!
> We are aware of @org.kie.api.definition.type.Position parameter of the field in the Data Object, but it does not solve our problem.
> How can we activate the sorting?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (DROOLS-1358) No sorting of the field names in the guided rules.
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1358?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-1358:
----------------------------------
Component/s: (was: kie server)
> No sorting of the field names in the guided rules.
> --------------------------------------------------
>
> Key: DROOLS-1358
> URL: https://issues.jboss.org/browse/DROOLS-1358
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Petr Farmakovsky
> Assignee: Michael Anstis
> Attachments: Field names.gif
>
>
> We use the Drools Workbench 6.3.0 Final. Our Data Object may consist of more than 20 fields. When writing rules, such as Guided Rules and when adding the object into the rule all fields are displayed unsorted: !Field names.gif!
> We are aware of @org.kie.api.definition.type.Position parameter of the field in the Data Object, but it does not solve our problem.
> How can we activate the sorting?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months