February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-153) Support DigestCredential with a specified realm name

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-153: ------------------------------------ Summary: Support DigestCredential with a specified realm name Key: ELY-153 URL: https://issues.jboss.org/browse/ELY-153 Project: WildFly Elytron Issue Type: Sub-task Components: Passwords Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha1 This would imply the password is retrievable and the realm associated by the authentication mechanism. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-152) Support for DigestCredential with static realm association.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-152: ------------------------------------ Summary: Support for DigestCredential with static realm association. Key: ELY-152 URL: https://issues.jboss.org/browse/ELY-152 Project: WildFly Elytron Issue Type: Sub-task Components: Passwords Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha1 This covers the use case where the users password is stored pre-hashed with the realm name. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-147) Default Methods on the RealmIdentity interface

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-147?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-147: --------------------------------- Description: Review how much of the RealmIdentity interface can have default method implementations, e.g. verification could be implemented if we can obtain the credential. Credential conversion is also another one we could cover, a mechanism should be able to start querying from the most specific type of credential it understands, if default methods on the realm can handle the conversion it will mean the mechanism can ignore the conversion. was:Review how much of the RealmIdentity interface can have default method implementations, e.g. verification could be implemented if we can obtain the credential. > Default Methods on the RealmIdentity interface > ---------------------------------------------- > > Key: ELY-147 > URL: https://issues.jboss.org/browse/ELY-147 > Project: WildFly Elytron > Issue Type: Feature Request > Components: API / SPI > Reporter: Darran Lofthouse > Fix For: 1.0.0.Alpha1 > > > Review how much of the RealmIdentity interface can have default method implementations, e.g. verification could be implemented if we can obtain the credential. > Credential conversion is also another one we could cover, a mechanism should be able to start querying from the most specific type of credential it understands, if default methods on the realm can handle the conversion it will mean the mechanism can ignore the conversion. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-151) Ability to supply additional information during credential acquisition

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-151: ------------------------------------ Summary: Ability to supply additional information during credential acquisition Key: ELY-151 URL: https://issues.jboss.org/browse/ELY-151 Project: WildFly Elytron Issue Type: Enhancement Components: API / SPI, Passwords Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha1 I think this is the final known gap in our credential acquisition and validation API/SPI. There are a couple of specifications that also allow for additional information to be used when obtaining a representation of a users credential, the most obvious being the session based variant of digest authentication where a nonce and cnonce are also incorporated. A second variant with two different modes of operation would be the realm associated with the digest credential, currently we assume it is tightly associated with the storage representation of the credential but it could also be the case that the mech is requesting it for a specific realm. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3174) Add view of batch jobs with ability to view, restart and stop

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3174?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-3174: ----------------------------------- That shouldn't be a problem, maybe from usability point of view, but otherwise it should work. > Add view of batch jobs with ability to view, restart and stop > ------------------------------------------------------------- > > Key: WFLY-3174 > URL: https://issues.jboss.org/browse/WFLY-3174 > Project: WildFly > Issue Type: Feature Request > Components: Batch > Reporter: James Perkins > Assignee: James Perkins > > Currently there is no way to view batch jobs for a deployment with in the batch subsystem management. There should be a way to view the batch jobs that have run on various deployments. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-436) Cannot access to remote kie maven repository - Access denied

by Rafael Fernández Sánchez (JIRA)

[ https://issues.jboss.org/browse/DROOLS-436?page=com.atlassian.jira.plugin... ] Rafael Fernández Sánchez commented on DROOLS-436: ------------------------------------------------- Hello, in version 6.2.0 CR4 how I can solve this problem?? Because i can not find this path and file: /WEB-INF/classes/url_filter.yaml and neither can to find settings.xml for maven > Cannot access to remote kie maven repository - Access denied > ------------------------------------------------------------ > > Key: DROOLS-436 > URL: https://issues.jboss.org/browse/DROOLS-436 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.1.Final > Environment: - Windows 7 64 bits > - JDK 1.7.0.45 > - Drools 6.0.1.Final > Reporter: Rogério Disciolli > Assignee: Mario Fusco > > - Start JBPM 6.0.1.Final binding a specific IP 192.168.0.10 > - Run maven in a remote machine with the pom.xml like this > <repository> > <id>guvnor-m2-repo</id> > <name>Guvnor M2 Repo</name> > <url>http://192.168.0.10:8080/jbpm-console/maven2/</url> > </repository> > Also having username/password in ~/.m2/settings.xml > <servers> > <server> > <id>guvnor-m2-repo</id> > <username>admin</username> > <password>admin</password> > </server> > </servers> > And returned "Access denied (401)" when try get maven-metadata.xml from project. > Can not authenticate at kie maven repository. > The same happens when try run Java Project with VM arguments "-Dkie.maven.settings.custom=settings.xml" -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4336) Cannot run testsuite if an application holds port 8080 open

by Michael Musgrove (JIRA)

Michael Musgrove created WFLY-4336: -------------------------------------- Summary: Cannot run testsuite if an application holds port 8080 open Key: WFLY-4336 URL: https://issues.jboss.org/browse/WFLY-4336 Project: WildFly Issue Type: Bug Components: Test Suite Affects Versions: 9.0.0.Alpha1 Reporter: Michael Musgrove We run jobs on a Jenkins cluster where the master is also a slave. The master runs the web front end gui on port 8080. The default wildfly web profile uses the same port. I tried starting undertow on a different port but the testsuite has some hardcoded references to port 8080, for example: testsuite/integration/src/test/xslt/changeIPAddresses.xsl testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/wsat/client/ATClient.java testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/wsba/coordinatorcompletion/client/BACoordinatorCompletionClient.java testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/wsba/participantcompletion/client/BAParticipantCompletionClient.java The particular command I tried was: {code} ./tools/maven/bin/mvn -s tools/maven/conf/settings.xml test '-f' './testsuite/integration/xts/pom.xml' '-Pxts.integration.tests.profile' -Djboss.http.port=xxx {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114)

by Li Jia (JIRA)

[ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin... ] Li Jia commented on DROOLS-329: ------------------------------- Hello, When can we expect a fix for this issue? Our product want to support JDK8. It become a blocking issue now. Thanks, Li > ClassFormatException when compile template with latest JDK8 (b114) > ------------------------------------------------------------------ > > Key: DROOLS-329 > URL: https://issues.jboss.org/browse/DROOLS-329 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final, 6.0.0.CR5 > Environment: Ubuntu linux, latest JDK1.8 (b114) downloaded from https://jdk8.java.net/download.html > Reporter: Marek Posolda > Assignee: Mark Proctor > Fix For: 5.5.1.Final, 6.2.0.Final > > > When trying to run code for compile templates with latest JDK8 (For instance this example https://github.com/droolsjbpm/drools/blob/master/drools-examples/src/main... ) > it will throw an exception like this: > {code} > Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: wrong class format > at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:148) > at org.drools.template.parser.DefaultTemplateRuleBase.<init>(DefaultTemplateRuleBase.java:62) > at org.drools.template.parser.TemplateDataListener.<init>(TemplateDataListener.java:74) > at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:95) > at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:81) > at org.drools.examples.templates.SimpleRuleTemplateExample.buildKBase(SimpleRuleTemplateExample.java:84) > at org.drools.examples.templates.SimpleRuleTemplateExample.executeExample(SimpleRuleTemplateExample.java:49) > at org.drools.examples.templates.SimpleRuleTemplateExample.main(SimpleRuleTemplateExample.java:43) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > Caused by: java.lang.RuntimeException: wrong class format > at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:263) > at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:203) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102) > at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49) > at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1188) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1244) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1031) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1193) > at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:495) > at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:577) > at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:327) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:640) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:619) > at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:133) > at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183) > at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:465) > at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:519) > at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:368) > at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:444) > at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:752) > at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:464) > at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:389) > at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49) > at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:371) > at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46) > at org.drools.compiler.PackageRegistry.compileAll(PackageRegistry.java:102) > at org.drools.compiler.PackageBuilder.compileAll(PackageBuilder.java:1006) > at org.drools.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:842) > at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:831) > at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:441) > at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:419) > at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:139) > ... 12 more > Caused by: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException > at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372) > at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287) > at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258) > ... 45 more > {code} > Workaround, which worked for me is to switch to Janino compiler (See Workaround description) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4335) ArquillianService incorrectly sets TCCL

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-4335?page=com.atlassian.jira.plugin.... ] Thomas Diesler reassigned WFLY-4335: ------------------------------------ Assignee: Thomas Diesler > ArquillianService incorrectly sets TCCL > --------------------------------------- > > Key: WFLY-4335 > URL: https://issues.jboss.org/browse/WFLY-4335 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 8.2.0.Final > Reporter: Thomas Diesler > Assignee: Thomas Diesler > > While integrating Camel in WildFly I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment. > Camel happens to rely on TCCL, which is of course questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else. > This shadows potential problems when TCCL is not set or set to something else. > Related: https://github.com/wildfly-extras/wildfly-camel/issues/292 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4335) ArquillianService incorrectly sets TCCL

by Thomas Diesler (JIRA)

Thomas Diesler created WFLY-4335: ------------------------------------ Summary: ArquillianService incorrectly sets TCCL Key: WFLY-4335 URL: https://issues.jboss.org/browse/WFLY-4335 Project: WildFly Issue Type: Bug Components: Test Suite Affects Versions: 8.2.0.Final Reporter: Thomas Diesler While integrating Camel in WildFly I noticed that @BeforeClass, @Before and @Test methods are being called with the TCCL of the test deployment. Camel happens to rely on TCCL, which is of course questionable in a modular environment. As a result it uses the test deployment's CL for resource discovery. Tests pass in the context of ARQ, but would not in a normal usage scenario when TCCL is not set or set to something else. This shadows potential problems when TCCL is not set or set to something else. Related: https://github.com/wildfly-extras/wildfly-camel/issues/292 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2015