October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1341) "unable to resolve method using strict-mode" MVEL exception when using function definitions in DRL

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-1341: ------------------------------------- Summary: "unable to resolve method using strict-mode" MVEL exception when using function definitions in DRL Key: DROOLS-1341 URL: https://issues.jboss.org/browse/DROOLS-1341 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.5.0.Final Reporter: Tibor Zimányi Assignee: Mario Fusco The test Misc2Test.testFunctionInvokingFunction() occasionally fails with following stacktrace [1]. It is probably some race condition, because the test runs multiple threads with different KieSessions accessing the same KieBase. [1] http://pastebin.com/8WWwYscQ -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7372) Hibernate Scanner implementation class shouldn't leak application entity classes

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7372?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-7372: ------------------------------- Affects Version/s: 10.1.0.Final JBoss AS7 7.2.0.Final > Hibernate Scanner implementation class shouldn't leak application entity classes > -------------------------------------------------------------------------------- > > Key: WFLY-7372 > URL: https://issues.jboss.org/browse/WFLY-7372 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: JBoss AS7 7.2.0.Final, 10.1.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7372) Hibernate Scanner implementation class shouldn't leak application entity classes

by Scott Marlow (JIRA)

Scott Marlow created WFLY-7372: ---------------------------------- Summary: Hibernate Scanner implementation class shouldn't leak application entity classes Key: WFLY-7372 URL: https://issues.jboss.org/browse/WFLY-7372 Project: WildFly Issue Type: Bug Components: JPA / Hibernate Reporter: Scott Marlow Assignee: Scott Marlow -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7367) add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7367?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-7367. ------------------------------ Resolution: Won't Do > add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader() > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7367 > URL: https://issues.jboss.org/browse/WFLY-7367 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > > The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call. > Ensure that the cached temp classloader reference is cleared after the PersistenceProvider.createContainerEntityManagerFactory() call returns. > Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnit...] > {quote} > ClassLoader getNewTempClassLoader() > Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call. > Returns: > temporary ClassLoader with same visibility as current loader > {quote} -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7367) add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader()

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7367?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-7367: ------------------------------------ potential implementation is pushed to https://github.com/scottmarlow/wildfly/commits/WFLY-7367_cachetempclasslo.... We would want to add a persistence unit hint check as well before merging. I'm going to address the entity class leak differently as Hibernate only seems to call getNewTempClassLoader once per persistence unit, its our ORM Scanner implementation code that needs to cache the new temp class loader instead (class leak is mostly from change for AS7-3085). > add per PU cache of the new temp classloader returned from PersistenceUnitMetadataImpl.getNewTempClassLoader() > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7367 > URL: https://issues.jboss.org/browse/WFLY-7367 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > > The new temporary classloader returned by the WildFly PersistenceUnitInfo.getNewTempClassLoader() is currently created on every call. > Ensure that the cached temp classloader reference is cleared after the PersistenceProvider.createContainerEntityManagerFactory() call returns. > Javadoc description from [http://docs.oracle.com/javaee/7/api/javax/persistence/spi/PersistenceUnit...] > {quote} > ClassLoader getNewTempClassLoader() > Return a new instance of a ClassLoader that the provider may use to temporarily load any classes, resources, or open URLs. The scope and classpath of this loader is exactly the same as that of the loader returned by getClassLoader(). None of the classes loaded by this class loader will be visible to application components. The provider may only use this ClassLoader within the scope of the PersistenceProvider.createContainerEntityManagerFactory(javax.persistence.spi.PersistenceUnitInfo, java.util.Map) call. > Returns: > temporary ClassLoader with same visibility as current loader > {quote} -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1052) Add server-config parameter to :reload op

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1052?page=com.atlassian.jira.plugi... ] Martin Choma commented on WFCORE-1052: -------------------------------------- [~kabirkhan], what are valid values for --server-config attribute? Relative files to {{standalone/configuration}} dir and {{standalone/configuration/standalone_xml_history/snapshot}} dir ? If that can't be change to accept absolute paths, could that be somehow documented? > Add server-config parameter to :reload op > ----------------------------------------- > > Key: WFCORE-1052 > URL: https://issues.jboss.org/browse/WFCORE-1052 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha1 > > > {code} > [13:48] Kabir Khan: @BrianStansberry @JasonGreene $./build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/bin/standalone.sh --server-config=20151013-134726769standalone.xml  looks for that file in the snapshots directory > [13:48] Kabir Khan: > [standalone@localhost:9990 /] :list-snapshots > { > "outcome" => "success", > "result" => { > "directory" => "/Users/kabir/sourcecontrol/wildfly/git/wildfly-core/build/target/wildfly-core-2.0.0.CR7-SNAPSHOT/standalone/configuration/standalone_xml_history/snapshot", > "names" => [ > "20151013-134523280standalone.xml", > "20151013-134726769standalone.xml" > ] > } > } > Show less > [13:50] Kabir Khan: server-config should probably be a parameter to the :reload operation > {code} > Similarly we should add host-config and domain-config parameters to the host's reload operation. Using domain-config on a non-DC host should fail. > For a domain server, we should not have the server-config parameter. > We should check the existence of the file before the reload actually is done, or we will end up in a sticky situation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2112) Sticky site masters

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2112?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2112: -------------------------------- Unit test: Relay2Test.testSenderOrderWithMultipleSiteMasters() > Sticky site masters > ------------------- > > Key: JGRP-2112 > URL: https://issues.jboss.org/browse/JGRP-2112 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.12, 4.0 > > > If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur. > Example: > * Member C in site LON sends messages C1 and C2 to site NYC > * C1 picks SM1 and C2 picks SM2 > * Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues > h4. Design > * When sending a message to the one of the site masters of the current site, or from a site master to a remote site master, we invoke a callback to pick the site master based on the original caller > * Note that this only applies when we have more than one site master. > * The callback passes the address of the original caller and the list of available site masters, and needs to return a site master > h5. Transactions > * Transactions by different originators with overlapping key sets cannot be reliably ordered > * Transactional support therefore requires single site masters > * This should not be an issue as transactions bundle multiple updates, so the number of messages sent is less than non-transactional updates -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-681) Hide private packages from generated javadoc.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-681: ------------------------------------ Summary: Hide private packages from generated javadoc. Key: ELY-681 URL: https://issues.jboss.org/browse/ELY-681 Project: WildFly Elytron Issue Type: Task Components: Build Reporter: Darran Lofthouse Priority: Critical Fix For: 1.1.0.Beta12 We may want two profiles so we can generate a full javadoc and a 'public' javadoc. The 'public' javadoc should be the default one generated and should exclude the following packages: - org.wildfly.security._private org.wildfly.security.asn1 org.wildfly.security.auth.realm org.wildfly.security.auth.realm.* org.wildfly.security.authz.jacc org.wildfly.security.credential.store.impl org.wildfly.security.security.digest org.wildfly.security.http.impl org.wildfly.security.security.keystore org.wildfly.security.mechanism.oauth2 org.wildfly.security.mechanism.scram org.wildfly.security.password.impl org.wildfly.security.password.util org.wildfly.security.pem org.wildfly.security.sasl org.wildfly.security.sasl.* (Except util) org.wildfly.security.util org.wildfly.security.util_private org.wildfly.security.x500 org.wildfly.security.x500.cert -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1891) Split WildFly Elytron into two modules with a public / private split.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-1891: ---------------------------------------- Summary: Split WildFly Elytron into two modules with a public / private split. Key: WFCORE-1891 URL: https://issues.jboss.org/browse/WFCORE-1891 Project: WildFly Core Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Fix For: 3.0.0.Alpha11 The Elytron jar will be contained within a private module, possibly 'elytron-private' then a module 'elytron' will depend on this and make the public packages visible. The following packages have been identified as being private: - org.wildfly.security._private org.wildfly.security.asn1 org.wildfly.security.auth.realm org.wildfly.security.auth.realm.* org.wildfly.security.authz.jacc org.wildfly.security.credential.store.impl org.wildfly.security.security.digest org.wildfly.security.http.impl org.wildfly.security.security.keystore org.wildfly.security.mechanism.oauth2 org.wildfly.security.mechanism.scram org.wildfly.security.password.impl org.wildfly.security.password.util org.wildfly.security.pem org.wildfly.security.sasl org.wildfly.security.sasl.* (Except util) org.wildfly.security.util org.wildfly.security.util_private org.wildfly.security.x500 org.wildfly.security.x500.cert -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7371) JAXRS endpoint - CDI injection to constructor doesn't work

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/WFLY-7371?page=com.atlassian.jira.plugin.... ] Tomas Remes commented on WFLY-7371: ----------------------------------- I think this is a RESTEasy issue. > JAXRS endpoint - CDI injection to constructor doesn't work > ---------------------------------------------------------- > > Key: WFLY-7371 > URL: https://issues.jboss.org/browse/WFLY-7371 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, REST > Affects Versions: 10.1.0.Final > Reporter: Tomas Remes > Assignee: Stuart Douglas > > Deploying app with following JAXRS endpoint > {code} > @Path("/test") > public class MyTimeResource { > private final LocalDateTime dateTime; > @Inject > public MyTimeResource(LocalDateTime dateTime){ > this.dateTime = dateTime; > }; > } > {code} > is failing with following stack trace: > {noformat} > Caused by: java.lang.RuntimeException: RESTEASY003190: Could not find constructor for class: org.example.microprofile.MyTimeResource > at org.jboss.resteasy.spi.metadata.ResourceBuilder.constructor(ResourceBuilder.java:692) > at org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory.registered(POJOResourceFactory.java:42) > at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:208) > at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:194) > at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:180) > at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:157) > at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:76) > at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:409) > at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:250) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:250) > at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:133) > at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:546) > at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:517) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:559) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > ... 6 more > {noformat} > Note that app contains beans.xml so the JAXRS resource should be really managed by CDI. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 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 October 2016