April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBLOGGING-111) LoggerProvider configured with new ServiceLoader crash

by Ghislain Nadeau (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-111?page=com.atlassian.jira.plu... ] Ghislain Nadeau commented on JBLOGGING-111: ------------------------------------------- I see there's a pull request sent, and looking at the pull request itself, it looks like it has been merged. Is it fixed? > LoggerProvider configured with new ServiceLoader crash > ------------------------------------------------------ > > Key: JBLOGGING-111 > URL: https://issues.jboss.org/browse/JBLOGGING-111 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.2.0.Beta1 > Environment: Weblogic 10.3.2.0 > Configured in ejb jar, deployed by an ear file > Reporter: Frederic Allard > Assignee: James Perkins > > There is a new feature in the beta which uses the ServiceLoader to specify a LoggerProvider to be used by JBoss Logging. > org.jboss.logging.LoggerProviders snippet : > {code} > // Next try for a service provider > try { > final ServiceLoader<LoggerProvider> loader = ServiceLoader.load(LoggerProvider.class, cl); > if (loader.iterator().hasNext()) { > return loader.iterator().next(); > } > } catch (Throwable ignore) { > // TODO consider printing the stack trace as it should only happen once > } > {code} > When you try to configure a provider (ex. org.jboss.logging.Slf4jLoggerProvider), the ServiceLoader crash silently and ignore the provider. > {code} > java.util.ServiceConfigurationError: org.jboss.logging.LoggerProvider: Provider org.jboss.logging.Slf4jLoggerProvider could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.jboss.logging.Slf4jLoggerProvider with modifiers "" > at java.util.ServiceLoader.fail(ServiceLoader.java:207) > at java.util.ServiceLoader.access$100(ServiceLoader.java:164) > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353) > at java.util.ServiceLoader$1.next(ServiceLoader.java:421) > at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:70) > at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:32) > at org.jboss.logging.LoggerProviders.<clinit>(LoggerProviders.java:29) > at org.jboss.logging.Logger.getLogger(Logger.java:2177) > at org.jboss.logging.Logger$1.run(Logger.java:2277) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2241) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2228) > at org.hibernate.cfg.Configuration.<clinit>(Configuration.java:176) > ... > {code} > This is caused by the fact that all JBoss providers are not public classes and are instead package classes. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4479) HornetQ Last Value Queue Contains Duplicates When Wildfly is Restarted.

by Abhishek Parikh (JIRA)

Abhishek Parikh created WFLY-4479: ------------------------------------- Summary: HornetQ Last Value Queue Contains Duplicates When Wildfly is Restarted. Key: WFLY-4479 URL: https://issues.jboss.org/browse/WFLY-4479 Project: WildFly Issue Type: Bug Components: Application Client Affects Versions: 8.1.0.Final Reporter: Abhishek Parikh Assignee: Stuart Douglas Priority: Critical HornetQ Last Value Queue Contains Duplicates When Wildfly is Restarted. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-380) Operations to read content from the content repository

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-380?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-380: --------------------------------------- Assignee: luck3y Ken, This may or may not conflict with the task of supporting exploded deployments in the content repository. Possible conflicts: 1) Adding an attribute for this just doesn't fit nicely with whatever API we add for managing exploding deployments. 2) Users may think this attribute will allow them to suck down a zipped version of an exploded deployment. (I guess this is a variant of 1) above.) It's ok to reschedule this out of 1.0.0.CR1 if you're concerned about adding this API now before the full picture is clear. > Operations to read content from the content repository > ------------------------------------------------------ > > Key: WFCORE-380 > URL: https://issues.jboss.org/browse/WFCORE-380 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: luck3y > Priority: Minor > Fix For: 1.0.0.CR1 > > > Ability to pull data out of the content repository. We can do that with rollout plans, but not for deployments or if we add deployment content overlays. > Basically, if the user loses the original of the deployment, let's let them get it back via the management API and remove the temptation for them to hack into the repository. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-43) Clarify the meaning of the 'server-state' and 'host-state' attributes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-43?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFCORE-43: -------------------------------------- Assignee: luck3y > Clarify the meaning of the 'server-state' and 'host-state' attributes > --------------------------------------------------------------------- > > Key: WFCORE-43 > URL: https://issues.jboss.org/browse/WFCORE-43 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: luck3y > Fix For: 1.0.0.CR1 > > > This JIRA is to implement what I described in the dev list discussion around the various states a server can be in for graceful shutdown (http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002360.html) > "I do think these are orthogonal and should not be combined. > The existing attribute is fundamentally about how the state of the > runtime services relates to the persistent configuration. > STARTING == out of sync due to still getting in sync during start > RUNNING == in sync > RELOAD_REQURIRED = out of sync, needs a reload to get in sync > RESTART_REQUIRED = out of sync, needs a full process restart to get in sync > There are two problems though with the existing attribute that exposes this: > 1) It's named "server-state" on a server and "host-state" on a Host > Controller. Really crappy name; way too broad. > That's fixable by creating a new attribute and making the old one an > alias for compatibility purposes. > 2) The RUNNING state is really poorly named. > The could perhaps be fixed by coming up with a new name and translating > it back to "RUNNING" in the handlers for the legacy "server-state" and > "host-state" attributes." -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (REMJMX-19) Optimise server side notifications to eliminate serialization issue re different instances of same filter and hand back server side.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-19?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated REMJMX-19: ----------------------------------- Fix Version/s: 2.0.2.CR1 (was: 2.0.1.CR2) > Optimise server side notifications to eliminate serialization issue re different instances of same filter and hand back server side. > ------------------------------------------------------------------------------------------------------------------------------------ > > Key: REMJMX-19 > URL: https://issues.jboss.org/browse/REMJMX-19 > Project: Remoting JMX > Issue Type: Task > Components: Notifications > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.2.CR1 > > > The NotificationMBeanSupport class compares these items by identity so when different copies are received server side it breaks these comparisons. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-362) fix jvm management model for server and groups

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-362?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-362: --------------------------------------- Assignee: luck3y > fix jvm management model for server and groups > ---------------------------------------------- > > Key: WFCORE-362 > URL: https://issues.jboss.org/browse/WFCORE-362 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: luck3y > Labels: rhq > Fix For: 1.0.0.CR1 > > > We need to update the JVM child resource definition for server-groups and servers to only allow a single JVM configuration (i.e. configuration=JVM) resource. Currently only the first configured VM is used, where the name is the reference to the corresponding host level JVM. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-384) Server does wrongly reference a list of socket binding groups

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-384?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-384: --------------------------------------- Assignee: luck3y > Server does wrongly reference a list of socket binding groups > ------------------------------------------------------------- > > Key: WFCORE-384 > URL: https://issues.jboss.org/browse/WFCORE-384 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Braun > Assignee: luck3y > Fix For: 1.0.0.CR1 > > > hbraun: i see that a server (host=foo/server=bar) can have a list of socket-binding-groups > [10:59am] hbraun: shouldn't that be a a single socket binding instead? > [11:00am] emuckenhuber: oh... yeah > [11:00am] hbraun: maybe it's just the description that's wrong > [11:00am] emuckenhuber: that sounds similar to the jvm thing we had -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (REMJMX-77) org.jboss.remoting-jmx.timeout is not used when connecting the first time

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-77?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved REMJMX-77. ------------------------------------ Resolution: Out of Date Updates have already been applied to timeout handling within RemotingConnector to correctly take into account all timeout settings. > org.jboss.remoting-jmx.timeout is not used when connecting the first time > ------------------------------------------------------------------------- > > Key: REMJMX-77 > URL: https://issues.jboss.org/browse/REMJMX-77 > Project: Remoting JMX > Issue Type: Bug > Affects Versions: 1.1.0.Final > Environment: EAP 6.1.1 > Reporter: Osamu Nagano > Assignee: Darran Lofthouse > Fix For: 2.0.1.CR2 > > > Timeout second is fixed at 5 seconds and not configurable when a client is trying to connect to the server first time. There is a constant "org.jboss.remoting-jmx.timeout" but it is not used here. > https://github.com/jbossas/remoting-jmx/blob/1.1.0.Final/src/main/java/or... > {code} > 207 // open a connection > 208 final IoFuture<Connection> futureConnection = endpoint.connect(convert(serviceUrl), getOptionMap(), handler); > 209 IoFuture.Status result = futureConnection.await(5, TimeUnit.SECONDS); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-396: --------------------------------------- Assignee: luck3y > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: luck3y > Fix For: 1.0.0.CR1 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-316) Slave host does not register to DC when starting with --cached-dc and DC is available

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-316?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-316: --------------------------------------- Assignee: luck3y Ken, I'm assigning this as one of several in the general area of how various Host Controllers interact. We should look at them in total and come up with a strategy, not do them piecemeal. > Slave host does not register to DC when starting with --cached-dc and DC is available > ------------------------------------------------------------------------------------- > > Key: WFCORE-316 > URL: https://issues.jboss.org/browse/WFCORE-316 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Manel Martinez Gonzalez > Assignee: luck3y > > NOTE: this is related to AS7-4281 (see https://issues.jboss.org/browse/AS7-4281?focusedCommentId=12682058&page=c... ) > When a slave host is started with --cached-dc option it won't register to Domain Controller although it's available. domain.sh help says "If this host is not the Domain Controller and cannot contact the Domain Controller at boot, boot using a locally cached copy of the domain configuration (see --backup)" and this is not really happening because slave host never contact to DC with --cached-dc -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

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