February 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-465) Cannot find KieModule with LATEST

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-465?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-465: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1303018|https://bugzilla.redhat.com/show_bug.cgi?id=1303018] from NEW to ASSIGNED > Cannot find KieModule with LATEST > --------------------------------- > > Key: DROOLS-465 > URL: https://issues.jboss.org/browse/DROOLS-465 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Beta1 > Reporter: Takami Hirata > Assignee: Mario Fusco > Attachments: reproducer.zip > > > I install a kmodule into local repository with command {{mvn clean install}}. > Loading this kmodule with 'LATEST' works on the day, but will fail on next day. > Maven will find update on next day because of default updatePolicy 'daily', then maven check local repository ({{org.kie.scanner.Aether}} treats as a remote repository) but local artifact cache does not have 'maven-metadata.xml' which remote artifact should have, so finding update fails and {{org.sonatype.aether.connector.file.FileRepositoryWorker}} removes {{maven-metadata-local.xml}} for cleanup. > {{org.kie.scanner.Aether}} adds local repository to remote repositories, but this may be incorrect usage. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header

by Gunnar Morling (JIRA)

[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ] Gunnar Morling commented on WFLY-6097: -------------------------------------- Ah, it appears that you are running into RESTEASY-1264. This is only triggered if the JAX-RS resource is a CDI bean (I head tried it with an EJB originally which is why I couldn't reproduce it). That issue also describes a possible work-around for the time being. > Error response handling from bean validation ignores Accept header > ------------------------------------------------------------------ > > Key: WFLY-6097 > URL: https://issues.jboss.org/browse/WFLY-6097 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Environment: Mac OS X El Captain > java version "1.8.0_66" > Java(TM) SE Runtime Environment (build 1.8.0_66-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) > Reporter: Renann Prado > Assignee: Jason Greene > Attachments: delivery-optimization-ear-1.0.Final.ear > > > Basically I have a very simple application that has request validation in the REST endpoints. > According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request. > https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati... > The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't. > I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final. > In WF 9.0.2.Final I used to get the below error *JSON* > {code:json} > { > "exception": null, > "fieldViolations": [], > "propertyViolations": [], > "classViolations": [], > "parameterViolations": [{ > "constraintType": "PARAMETER", > "path": "registerLogisticsNetwork.arg0.name", > "message": "may not be null", > "value": "" > }], > "returnValueViolations": [] > } > {code} > In WF 10.0.0.Final I get this: > {code} > [PARAMETER] > [registerLogisticsNetwork.arg0.name] > [may not be null] > [] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6097) Error response handling from bean validation ignores Accept header

by Gunnar Morling (JIRA)

[ https://issues.jboss.org/browse/WFLY-6097?page=com.atlassian.jira.plugin.... ] Gunnar Morling commented on WFLY-6097: -------------------------------------- Can you attach the sources of a simple example (e.g. without database interactions) and your invocation of the REST endpoint, please? Maybe you are not specifying the accept header correctly. It works as expected for me, when specifying the request header "Accept: application/json", I'll get back a JSON response, otherwise the plain text representation (the -1 in the payload is violating a constraint of my example service): {code} curl -XPOST <MY_URL> -H "Content-Type: application/json" -H "Accept: application/json" -d '-1' {code} {code} {"exception":null,"fieldViolations":[],"propertyViolations":[],"classViolations":[],"parameterViolations":[{"constraintType":"PARAMETER","path":"test.arg0","message":"must be greater than or equal to 1","value":"-1"}],"returnValueViolations":[]}% {code} > Error response handling from bean validation ignores Accept header > ------------------------------------------------------------------ > > Key: WFLY-6097 > URL: https://issues.jboss.org/browse/WFLY-6097 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Environment: Mac OS X El Captain > java version "1.8.0_66" > Java(TM) SE Runtime Environment (build 1.8.0_66-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) > Reporter: Renann Prado > Assignee: Jason Greene > Attachments: delivery-optimization-ear-1.0.Final.ear > > > Basically I have a very simple application that has request validation in the REST endpoints. > According to the documentation of RESTEasy, I should get a JSON error response if I put "application/json" in Accept header in the request. > https://docs.jboss.org/resteasy/docs/3.0.13.Final/userguide/html/Validati... > The mentioned feature worked just fine in Wildfly 9.0.2.Final. Now, however, it doesn't. > I have tried to upgrade the dependencies in the pom.xml to use dependencies from Wildfly 10.0.0.Final, but still no luck. Though the attached application deploys just fine in Wildfly 9.0.2.Final and Wildfly 10.0.0.Final. > In WF 9.0.2.Final I used to get the below error *JSON* > {code:json} > { > "exception": null, > "fieldViolations": [], > "propertyViolations": [], > "classViolations": [], > "parameterViolations": [{ > "constraintType": "PARAMETER", > "path": "registerLogisticsNetwork.arg0.name", > "message": "may not be null", > "value": "" > }], > "returnValueViolations": [] > } > {code} > In WF 10.0.0.Final I get this: > {code} > [PARAMETER] > [registerLogisticsNetwork.arg0.name] > [may not be null] > [] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5343) Datasource configuration allows editing driver name to non-existing one

by Bartosz Baranowski (JIRA)

[ https://issues.jboss.org/browse/WFLY-5343?page=com.atlassian.jira.plugin.... ] Bartosz Baranowski closed WFLY-5343. ------------------------------------ Resolution: Won't Fix Designed this way. Activation phase does all checks. > Datasource configuration allows editing driver name to non-existing one > ----------------------------------------------------------------------- > > Key: WFLY-5343 > URL: https://issues.jboss.org/browse/WFLY-5343 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Jan Kašík > Assignee: Bartosz Baranowski > > When editing datasource attributes, JDBC driver name can be changed to driver which is not installed (deployed) without any error message being showed. Although error message "A driver needs to be specified or chosen!" is showed if driver, which is not present in system, is filled in form during addition of new datasource. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5569) Module dependencies don't work correctly when JAAS login is used in deployments

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-5569?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-5569. ------------------------------------ Fix Version/s: 10.1.0.Final Resolution: Won't Fix This is going to be superseded by Elytron at some point anyway, however as from my initial assessment this is far from trivial to address so the application is required to take responsibility for class loading if it is using the LoginContext directly. > Module dependencies don't work correctly when JAAS login is used in deployments > ------------------------------------------------------------------------------- > > Key: WFLY-5569 > URL: https://issues.jboss.org/browse/WFLY-5569 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Fix For: 10.1.0.Final > > > When user wants to use direct JAAS login call from a deployment (e.g. servlet), (s)he will experience problems when LoginModule is placed in custom AS module. > Login modules works correctly if they come from PicketBox, but new modules doesn't work. > This issue is based on [this StackOverflow question|http://stackoverflow.com/questions/33203277/wildfly-and-jaas-log...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5569) Module dependencies don't work correctly when JAAS login is used in deployments

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-5569?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-5569: -------------------------------------- Assignee: Darran Lofthouse > Module dependencies don't work correctly when JAAS login is used in deployments > ------------------------------------------------------------------------------- > > Key: WFLY-5569 > URL: https://issues.jboss.org/browse/WFLY-5569 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Darran Lofthouse > > When user wants to use direct JAAS login call from a deployment (e.g. servlet), (s)he will experience problems when LoginModule is placed in custom AS module. > Login modules works correctly if they come from PicketBox, but new modules doesn't work. > This issue is based on [this StackOverflow question|http://stackoverflow.com/questions/33203277/wildfly-and-jaas-log...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6125) [Migration operation] No migration warning for remoting-interceptors

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-6125?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-3210 to WFLY-6125: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6125 (was: JBEAP-3210) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) (was: Migration) Target Release: (was: 7.0.0.GA) Affects Version/s: 10.0.0.Final (was: 7.0.0.ER4) > [Migration operation] No migration warning for remoting-interceptors > -------------------------------------------------------------------- > > Key: WFLY-6125 > URL: https://issues.jboss.org/browse/WFLY-6125 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > There is missing warning if following configuration is migrated to messaging-activemq subsystem: > {code} > <remoting-interceptors> > <class-name> > org.jboss.qa.hornetq.apps.interceptors.LargeMessagePacketInterceptorImpl > </class-name> > <class-name> > org.jboss.qa.hornetq.apps.interceptors.LargeMessagePacketInterceptorImpl > </class-name> > </remoting-interceptors> > {code} > There should be warning like: > {{WFLYMSG0082: Classes providing the remoting-incoming-interceptors are discarded during the migration. To use them in the new messaging-activemq subsystem, you will have to extend the Artemis-based Interceptor.}} > as for migration of remoting-incoming-interceptors and remoting-outgoing-interceptors. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6124) Infinispan subsystem XSD disagrees with LockingResourceDefinition on default isolation level

by Ladislav Thon (JIRA)

[ https://issues.jboss.org/browse/WFLY-6124?page=com.atlassian.jira.plugin.... ] Ladislav Thon updated WFLY-6124: -------------------------------- Affects Version/s: 10.0.0.Final > Infinispan subsystem XSD disagrees with LockingResourceDefinition on default isolation level > -------------------------------------------------------------------------------------------- > > Key: WFLY-6124 > URL: https://issues.jboss.org/browse/WFLY-6124 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Ladislav Thon > Assignee: Paul Ferraro > > The XSD for the Infinispan subsystem ({{jboss-as-infinispan_4_0.xsd}}) says that the default isolation level is {{REPEATABLE_READ}}: > {code} > <xs:complexType name="locking"> > <xs:attribute name="isolation" type="tns:isolation" default="REPEATABLE_READ"> > <xs:annotation> > <xs:documentation>Sets the cache locking isolation level.</xs:documentation> > </xs:annotation> > </xs:attribute> > ... > {code} > However, the {{LockingResourceDefinition}} class, which is the ultimate source of truth, disagrees: > {code} > enum Attribute implements org.jboss.as.clustering.controller.Attribute { > ... > ISOLATION("isolation", ModelType.STRING, new ModelNode(IsolationLevel.READ_COMMITTED.name()), new EnumValidatorBuilder<>(IsolationLevel.class)), > ... > {code} > I'm not sure myself which one should be the default, but this difference is surely a bug. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6124) Infinispan subsystem XSD disagrees with LockingResourceDefinition on default isolation level

by Ladislav Thon (JIRA)

Ladislav Thon created WFLY-6124: ----------------------------------- Summary: Infinispan subsystem XSD disagrees with LockingResourceDefinition on default isolation level Key: WFLY-6124 URL: https://issues.jboss.org/browse/WFLY-6124 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Ladislav Thon Assignee: Paul Ferraro The XSD for the Infinispan subsystem ({{jboss-as-infinispan_4_0.xsd}}) says that the default isolation level is {{REPEATABLE_READ}}: {code} <xs:complexType name="locking"> <xs:attribute name="isolation" type="tns:isolation" default="REPEATABLE_READ"> <xs:annotation> <xs:documentation>Sets the cache locking isolation level.</xs:documentation> </xs:annotation> </xs:attribute> ... {code} However, the {{LockingResourceDefinition}} class, which is the ultimate source of truth, disagrees: {code} enum Attribute implements org.jboss.as.clustering.controller.Attribute { ... ISOLATION("isolation", ModelType.STRING, new ModelNode(IsolationLevel.READ_COMMITTED.name()), new EnumValidatorBuilder<>(IsolationLevel.class)), ... {code} I'm not sure myself which one should be the default, but this difference is surely a bug. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1017) NPE deleting an expired event in equality mode

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1017?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on DROOLS-1017: ------------------------------------------------- Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1295433|https://bugzilla.redhat.com/show_bug.cgi?id=1295433] from MODIFIED to ON_QA > NPE deleting an expired event in equality mode > ---------------------------------------------- > > Key: DROOLS-1017 > URL: https://issues.jboss.org/browse/DROOLS-1017 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.0.Beta1 > > > Trying to delete an already expired event in equality mode causes the following NPE in the TMS: > {code} > java.lang.NullPointerException > at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:506) > at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:442) > at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1120) > at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:121) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003) > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274) > at org.drools.compiler.integrationtests.CepEspTest.testDeleteExpiredEventWithTimestampAndEqualityKey(CepEspTest.java:5682) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2016