April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by John Mezzetta (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] John Mezzetta commented on LOGMGR-120: -------------------------------------- Thanks James! We are give you feedback regarding our performance testing using the solution within the next few days. Regards, John > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > Attachments: force_logging.patch > > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1261) Rework pool policies

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1261?page=com.atlassian.jira.plugin... ] Jesper Pedersen reopened JBJCA-1261: ------------------------------------ > Rework pool policies > -------------------- > > Key: JBJCA-1261 > URL: https://issues.jboss.org/browse/JBJCA-1261 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.2.4.Final > > > Let the pool policy (FIFO/FILO) be defined by its decrementer policy -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1261) Rework pool policies

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1261?page=com.atlassian.jira.plugin... ] Jesper Pedersen closed JBJCA-1261. ---------------------------------- Fix Version/s: 1.1.10.Final Resolution: Done > Rework pool policies > -------------------- > > Key: JBJCA-1261 > URL: https://issues.jboss.org/browse/JBJCA-1261 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.1.10.Final, 1.2.4.Final > > > Let the pool policy (FIFO/FILO) be defined by its decrementer policy -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4448) Batch creates a JdbcJobRepository per deployment where only one global repository should be used

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-4448?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFLY-4448: ------------------------------------- The resources to display batch jobs from the console will live on the deployment. In CLI the path is {{/deployment=my.war/subsystem=batch/}}. This is where jobs will be displayed by the job name. {code:title=Example CLI output} [standalone@localhost:9990 /] /deployment=batch-chunk.war/subsystem=batch:read-resource(include-runtime=true,recursive=true) { "outcome" => "success", "result" => {"job" => {"chunkPartition" => { "instance-count" => 1, "running-executions" => 0, "execution" => {"1" => { "batch-status" => "COMPLETED", "create-time" => "2015-04-14T11:29:39.008-0700", "end-time" => "2015-04-14T11:29:39.033-0700", "exit-status" => "COMPLETED", "instance-id" => 1L, "last-updated-time" => "2015-04-14T11:29:39.033-0700", "start-time" => "2015-04-14T11:29:39.008-0700" }} }}} } {code} If a deployment uses a shared JDBC data source (the only current option) they could see all jobs from all applications using the same data source. The management operations will limit the available jobs to those allowed to be seen by the deployment. We may be able to add that constraint by overriding the {{JobOperator}}. I'm not sure we want to go there at this point though. > Batch creates a JdbcJobRepository per deployment where only one global repository should be used > ------------------------------------------------------------------------------------------------ > > Key: WFLY-4448 > URL: https://issues.jboss.org/browse/WFLY-4448 > Project: WildFly > Issue Type: Bug > Components: Batch > Reporter: James Perkins > Assignee: James Perkins > > When the batch subsystem is configured to use a JDBC job repository a new {{JdbcJobRepository}} is created for each application deployed. A global {{JdbcJobRepository}} should be used. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-120) Thread local log level overriding

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-120: -------------------------------------- To use this feature set the {{org.jboss.logmanager.useThreadLocalFilter}} system property to {{true}}. In WildFly this would need to be done in the {{standalone.conf(.bat)}} by adding {{-Dorg.jboss.logmanager.useThreadLocalFilter=true}} to the {{JAVA_OPTS}}. Then use {{LogManager.setThreadLocalLogLevel(Filter)}} to set the filter for the thread. To remove the filter pass {{null}} to the setter. > Thread local log level overriding > --------------------------------- > > Key: LOGMGR-120 > URL: https://issues.jboss.org/browse/LOGMGR-120 > Project: JBoss Log Manager > Issue Type: Feature Request > Components: core > Affects Versions: 1.5.2.Final > Reporter: Matthew Robson > Assignee: James Perkins > Attachments: force_logging.patch > > > Having the ability to force logs down to a filter no matter what the log level is set to. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-642) ReadOperationDescriptionHandler doesn't handle multi-process wildcard addresses nicely

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-642: --------------------------------------- Summary: ReadOperationDescriptionHandler doesn't handle multi-process wildcard addresses nicely Key: WFCORE-642 URL: https://issues.jboss.org/browse/WFCORE-642 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 1.0.0.CR1 Getting WFCORE-282 to work surfaces a problem with :read-operation-description handling, which will get invoked in the background by the CLI whenever the user inputs a wildcard read op. Problem is ReadOperationDescriptionHandler.getDescribedOp, which attempts to deal with cases where there is no resource registration for the target address. It checks if the request is for a wildcard address, and if so it sees if there are concrete registrations for that address, and if so whether they all use the same description. If yes, it provides the description. This is broken in a couple ways: 1) It assumes the wildcard applies to the last element in the address, which may not be the case with ops that support wildcard addressing schemes. 2) It looks vulnerable to problems with proxy resources, particularly the /host=* case on the DC where there can be a normal ConcreteResourceRegistration for the local host=master child, and then ProxyControllerRegistration instances for the various host=slave-x registrations. I suspect this might lead to false results. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4517) Do not expose Infinispan bits to deployments importing the Hibernate main module

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-4517?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-4517: ------------------------------------ Currently, we have: org.hibernate:main which has hibernate-core, hibernate-infinispan, hibernate-entitymanager If we move hibernate-infinispan to a separate static module, the application classpath will still only contain the org.hibernate:main static module, which happens not contain the hibernate-infinispan classes anymore but I assume would still reference them. In other words, org.hibernate.main currently is a {hibernate-core, hibernate-infinispan, hibernate-entitymanager} and has a reference to org.infinispan:main. If I understand this jira correctly, the change will be that org.hibernate.main is a {hibernate-code, hibernate-entitymanager} and has a reference to hibernate-infinspan (which has a reference to org.infinispan:main). > Do not expose Infinispan bits to deployments importing the Hibernate main module > -------------------------------------------------------------------------------- > > Key: WFLY-4517 > URL: https://issues.jboss.org/browse/WFLY-4517 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > > This is mainly a follow up to > https://bugzilla.redhat.com/show_bug.cgi?id=1202911 > But also a consequence of difficulties I had with Hibernate Search (which depends on both latest Infinispan and the Hibernate version in WildFly), and Hibernate OGM (which requires Hibernate ORM but has strong coupling with specific versions of Infinispan). > The gist of the problem is that the module org.hibernate:main includes the integration code with Infinispan for second level caching. > While I agree people will want to enable the second level caching, I don't think they should be exposed to it, so I'll propose some changes. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4517) Do not expose Infinispan bits to deployments importing the Hibernate main module

by Sanne Grinovero (JIRA)

Sanne Grinovero created WFLY-4517: ------------------------------------- Summary: Do not expose Infinispan bits to deployments importing the Hibernate main module Key: WFLY-4517 URL: https://issues.jboss.org/browse/WFLY-4517 Project: WildFly Issue Type: Enhancement Components: JPA / Hibernate Reporter: Sanne Grinovero Assignee: Sanne Grinovero This is mainly a follow up to https://bugzilla.redhat.com/show_bug.cgi?id=1202911 But also a consequence of difficulties I had with Hibernate Search (which depends on both latest Infinispan and the Hibernate version in WildFly), and Hibernate OGM (which requires Hibernate ORM but has strong coupling with specific versions of Infinispan). The gist of the problem is that the module org.hibernate:main includes the integration code with Infinispan for second level caching. While I agree people will want to enable the second level caching, I don't think they should be exposed to it, so I'll propose some changes. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-763) Allow to create a KieBuilder using a specific ClassLoader

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-763: ---------------------------------- Summary: Allow to create a KieBuilder using a specific ClassLoader Key: DROOLS-763 URL: https://issues.jboss.org/browse/DROOLS-763 Project: Drools Issue Type: Feature Request Reporter: Mario Fusco Assignee: Mario Fusco Priority: Critical At the moment it is not possible to pass a ClassLoader to the KieBuilder used to programmatically create a KieModule -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4448) Batch creates a JdbcJobRepository per deployment where only one global repository should be used

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-4448?page=com.atlassian.jira.plugin.... ] Cheng Fang commented on WFLY-4448: ---------------------------------- They are still backed by the same data store, right? Now that the repository cache and data store can contain different data, we must be careful not to pollute each application's JdbcRepository from running jdbc queries. Using separate JdbcRepository gives better isolation, but can be difficult to work with from admin side. How do you show job data in admin console or CLI? Group them by application so each application can just display its own jobs, or aggregate them from all JdbcRepository? > Batch creates a JdbcJobRepository per deployment where only one global repository should be used > ------------------------------------------------------------------------------------------------ > > Key: WFLY-4448 > URL: https://issues.jboss.org/browse/WFLY-4448 > Project: WildFly > Issue Type: Bug > Components: Batch > Reporter: James Perkins > Assignee: James Perkins > > When the batch subsystem is configured to use a JDBC job repository a new {{JdbcJobRepository}} is created for each application deployed. A global {{JdbcJobRepository}} should be used. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 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 April 2015