July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5485) Move test cases from drools-compiler to drools-model-compiler

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-5485: ----------------------------------------- Summary: Move test cases from drools-compiler to drools-model-compiler Key: DROOLS-5485 URL: https://issues.redhat.com/browse/DROOLS-5485 Project: Drools Issue Type: Task Components: core engine, executable model Affects Versions: 7.39.0.Final Reporter: Toshiya Kobayashi Assignee: Toshiya Kobayashi Move test cases from drools-compiler to drools-model-compiler so that we can increase the test coverage for executable-model. At the moment, I'm not yet sure how many of the test cases can be moved. Basically DRL based test only. Luca noted: > there are some tests in -compiler that are not supported in the model compiler (I'm thinking about all the ASM/type generation related). That should be left in -compiler and hopefully moved outside like the traits If we find test failures by executable-model, we would spawn new JIRAs to deal with them one-by-one. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-5029) server group deployment resource doesn't include correct "mananged" value

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFCORE-5029?page=com.atlassian.jira.plug... ] Chao Wang updated WFCORE-5029: ------------------------------ Summary: server group deployment resource doesn't include correct "mananged" value (was: server group deployment resource doesn't include deployment content attribute and correct "mananged" value) > server group deployment resource doesn't include correct "mananged" value > ------------------------------------------------------------------------- > > Key: WFCORE-5029 > URL: https://issues.redhat.com/browse/WFCORE-5029 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 13.0.0.Beta1 > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Minor > > Unmanaged deploys show a checkmark that they are "managed" if you view the deployment under Server Groups. The deployment does however show correctly that it is un-managed in the Content Repository section. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13600) EJB client over HTTP Fail on Java SE

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13600?page=com.atlassian.jira.plugi... ] Cheng Fang commented on WFLY-13600: ----------------------------------- When using http protocol, you will need to set up authentication, on both server side and client side. On the server side, run {{$JBOSS_HOME/bin/add-user.sh}} to set up application users. On the client side, configure it in {{wildfly-config.xml}}: {code:xml} <configuration> <authentication-client xmlns="urn:elytron:client:1.2"> <authentication-rules> <rule use-configuration="default"/> </authentication-rules> <authentication-configurations> <configuration name="default"> <sasl-mechanism-selector selector="DIGEST-MD5"/> <set-user-name name="user1"/> <credentials> <clear-password password="user1!!!"/> </credentials> ... ... </configuration> </authentication-configurations> </authentication-client> </configuration> {code} > EJB client over HTTP Fail on Java SE > ------------------------------------ > > Key: WFLY-13600 > URL: https://issues.redhat.com/browse/WFLY-13600 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 20.0.0.Final > Reporter: Gergely Molnár > Assignee: Cheng Fang > Priority: Major > > Java SE code: > {code:java} > public class Application { > private static final String REMOTE_CALC = "ejb:/remote-ejb/RemoteCalc!" + RemoteCalc.class.getName(); > /** > * Lookup remote \{@link RemoteCalc}. > * > * @return a \{@link RemoteCalc} object > * @throws NamingException Something is wrong > */ > public static RemoteCalc getRemoteCalc() throws NamingException { > Hashtable<String, Object> jndiProps = new Hashtable<>(); > jndiProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory"); > // remote+http connection (work fine) > //jndiProps.put(Context.PROVIDER_URL, "remote+http://127.0.0.1:8080/remote-ejb"); > // http connection (fail) > jndiProps.put(Context.PROVIDER_URL, "http://127.0.0.1:8080/wildfly-services"); > Context context = new InitialContext(jndiProps); > return (RemoteCalc) context.lookup(REMOTE_CALC); > } > /** > * Call to run (main). > * > * @param args parameters (not used) > * @throws NamingException Something is wrong > */ > public static void main(String[] args) throws NamingException { > > RemoteCalc remoteCalc = getRemoteCalc(); > System.out.println("Remote calc 95 + 76: " + remoteCalc.add(95, 76)); > } > } > {code} > Exception: > Exception in thread "main" javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "http" > at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808) > at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140) > at javax.naming.InitialContext.lookup(Unknown Source) > at com.bosch.emea.bpart.remoteejbclient.Application.getRemoteCalc(Application.java:34) > at com.bosch.emea.bpart.remoteejbclient.Application.main(Application.java:47) > Lib: > {code:java} > @Remote > public interface RemoteCalc { > /** > * Add two integer. > * > * @param a an integer > * @param b an integer > * @return a + b > */ > public int add(int a, int b); > > } > {code} > Config: > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <configuration> > <authentication-client xmlns="urn:elytron:1.0"> > <authentication-rules> > <rule use-configuration="default" /> > </authentication-rules> > <authentication-configurations> > <configuration name="default"> > <sasl-mechanism-selector selector="#ALL" /> > <set-mechanism-properties> > <property key="wildfly.sasl.local-user.quiet-auth" value="true" /> > </set-mechanism-properties> > <providers> > <use-service-loader/> > </providers> > </configuration> > </authentication-configurations> > </authentication-client> > </configuration> > {code} > Maven dependency: > {code:xml} > <dependency> > <groupId>org.wildfly</groupId> > <artifactId>wildfly-ejb-client-bom</artifactId> > <version>20.0.0.Final</version> > <type>pom</type> > </dependency> > {code} > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13641) WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml

by Matěj Novotný (Jira)

[ https://issues.redhat.com/browse/WFLY-13641?page=com.atlassian.jira.plugi... ] Matěj Novotný commented on WFLY-13641: -------------------------------------- Hi, so, you have two deployments, an EAR (with lib) and then a separate WAR. WAR declares a dep on EAR/lib via {{jboss-deployment-structure.xml}}. Do I get that right? Fairly speaking, I am not familiar with how this should (if it should) work together. An opinion of someone well-versed in this would be nice - e.g. can you even load the jandex index of a completely different deployment? Looking at {{ExtenalBeanArchiveProcessor}}, [the code|https://github.com/wildfly/wildfly/blob/20.0.0.Final/weld/subsystem/...] you mention means that we are unable to load the Jandex index, hence we try to create it on the fly and fail there as well. > WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13641 > URL: https://issues.redhat.com/browse/WFLY-13641 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 20.0.0.Final > Reporter: Jens Viebig > Assignee: Matěj Novotný > Priority: Major > > When referencing a jar with CDI scan mode "annotaded" inside an ear from an external war via jboss-deployment-structure.xml a warning will be printed for every class: > WFLYWELD0055: Could not index class [Someclass] from an external bean archive: vfs:/somepath/myear.ear/myejb-0.0.1.jar/META-INF/beans.xml > Seems VFS cannot get hold of the classes. > The warning is logged in ExternalBeanArchiveProcessor which catches an EOFException from the inputstream loading the class. (Line 284). Seems the input stream is not able to load a single byte from the class -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5484) DMN test DT in context reports warn of no matched rules

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5484?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5484: ----------------------------------- Description: follows up on https://github.com/kiegroup/drools/commit/01e8ff9d9a38e3232d532c879b24a8a... and https://github.com/kiegroup/drools/commit/49be6c816880f64262eb0cdb08bcb59... to make sure the WARN of no matched rules also applies when the DT is in context (entries and result) > DMN test DT in context reports warn of no matched rules > ------------------------------------------------------- > > Key: DROOLS-5484 > URL: https://issues.redhat.com/browse/DROOLS-5484 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > follows up on > https://github.com/kiegroup/drools/commit/01e8ff9d9a38e3232d532c879b24a8a... > and > https://github.com/kiegroup/drools/commit/49be6c816880f64262eb0cdb08bcb59... > to make sure the WARN of no matched rules also applies when the DT is in context (entries and result) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5484) DMN test DT in context reports warn of no matched rules

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-5484: -------------------------------------- Summary: DMN test DT in context reports warn of no matched rules Key: DROOLS-5484 URL: https://issues.redhat.com/browse/DROOLS-5484 Project: Drools Issue Type: Task Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5483) RulesByteArray is never persistent into SessionInfo Table

by Agustino Alim (Jira)

Agustino Alim created DROOLS-5483: ------------------------------------- Summary: RulesByteArray is never persistent into SessionInfo Table Key: DROOLS-5483 URL: https://issues.redhat.com/browse/DROOLS-5483 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.39.0.Final Reporter: Agustino Alim Assignee: Mario Fusco Hello, When I deploy KIE Application into Karaf which doesn't support build-in capability of TransactionSynchronizationRegistry, so it will fallback into implementation with ThreadLocal [https://github.com/kiegroup/drools/blob/master/drools-persistence/drools-...] What's happening is during commit, the transaction resource is always clear no matter the caller own the transaction or not. {code:java} public void commit(boolean transactionOwner) { if ( transactionOwner ) { try { this.ut.commit(); } catch ( Exception e ) { logger.warn( "Unable to commit transaction", e); throw new RuntimeException( "Unable to commit transaction", e ); } } transactionResources.get().clear(); } {code} This causes rulesbytearray field in sessioninfo table is not persisted. Please refer to comment from ngs-mtech on [JtaTransactionManager.java|https://github.com/kiegroup/drools/commit/... [https://github.com/kiegroup/drools/commit/6189bdfaed78d540b464b83bcf6de5b...] -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5482) Extending integration tests to cover transformations

by Gabriele Cardosi (Jira)

Gabriele Cardosi created DROOLS-5482: ---------------------------------------- Summary: Extending integration tests to cover transformations Key: DROOLS-5482 URL: https://issues.redhat.com/browse/DROOLS-5482 Project: Drools Issue Type: Sub-task Reporter: Gabriele Cardosi Assignee: Gabriele Cardosi Extend integration tests to cover tranformations implementation (Apply/FieldRef/Constant) - eventually fixing bug -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5473) Implement DefineFunction scheleton

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5473?page=com.atlassian.jira.plug... ] Gabriele Cardosi closed DROOLS-5473. ------------------------------------ > Implement DefineFunction scheleton > ---------------------------------- > > Key: DROOLS-5473 > URL: https://issues.redhat.com/browse/DROOLS-5473 > Project: Drools > Issue Type: Sub-task > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > Labels: TrustyAI > > Implement DefineFunction management scheleton. > DefineFunctions are similar to DerivedFields, since both make usage of EXPRESSION. > Differences are > 1) DerivedFields methods should referenced inside "transformations" map, DefineFunctions not > 2) DerivedFields methods names are automatically generated, while DefineFunctions ones are retrieved from DefinedFunctions declaration > 3) DefineFunctions requires at least one Parameter (beside the List of already defined fields ) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13642) Legacy store=remote throws NCDFE at runtime

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13642?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13642: -------------------------------- Workaround Description: If the remote-store is not configured with rawtypes enabled, then it *should* use the persistence marshaller, and not try to instantiate its own JBoss Marshaller. Workaround: Workaround Exists > Legacy store=remote throws NCDFE at runtime > ------------------------------------------- > > Key: WFLY-13642 > URL: https://issues.redhat.com/browse/WFLY-13642 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 20.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > Fix For: 20.0.1.Final > > > The remote-store references a marshaller from the infinispan jboss-marshalling module, which WF does not include, thus throws a NoClassDefFoundError at runtime if one is configured. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

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 July 2020