[JBoss JIRA] (LOGMGR-54) org.jboss.logmanager.handlers.AsyncHandler.AsyncTask should call flush when queue runs empty
by Rico Neubauer (JIRA)
Rico Neubauer created LOGMGR-54:
-----------------------------------
Summary: org.jboss.logmanager.handlers.AsyncHandler.AsyncTask should call flush when queue runs empty
Key: LOGMGR-54
URL: https://issues.jboss.org/browse/LOGMGR-54
Project: JBoss Log Manager
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: core
Affects Versions: 1.3.2.Final, 1.4.0.Beta1
Reporter: Rico Neubauer
Assignee: David Lloyd
When using the org.jboss.logmanager.handlers.AsyncHandler in combination with handlers that use autoFlush=false it happens that output stalls when queue runs empty.
A workaround is to set autoflush=true, however this introduces a flush always, even if there are more records in the queue, which render the flush useless.
An optimization is to invoke flush() on the handlers if the AsyncTask's queue ran empty - since then there is nothing else to do anyhow.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6056) Implement a consistent integration plugin API
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6056?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler moved JBOSGI-621 to AS7-6056:
--------------------------------------------
Project: Application Server 7 (was: JBoss OSGi)
Key: AS7-6056 (was: JBOSGI-621)
Workflow: GIT Pull Request workflow (was: jira)
Component/s: OSGi
(was: Core Framework)
Security: (was: Public)
Fix Version/s: 7.2.0.Alpha1
(was: JBossOSGi 1.2.0)
> Implement a consistent integration plugin API
> ---------------------------------------------
>
> Key: AS7-6056
> URL: https://issues.jboss.org/browse/AS7-6056
> Project: Application Server 7
> Issue Type: Task
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 7.2.0.Alpha1
>
>
> Currently there are a number of different approaches for OSGi Framework/AS7 integration. These should be consolidated and all integration should be done through the SPI. Changes to the SPI can then be properly reflected on the (semantic) version of the framework
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6054) OSGi Bundle Resolution Exception not being revealed
by Ed Roberts (JIRA)
Ed Roberts created AS7-6054:
-------------------------------
Summary: OSGi Bundle Resolution Exception not being revealed
Key: AS7-6054
URL: https://issues.jboss.org/browse/AS7-6054
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows XP SP2
Oracle JDK 1.6.0_32
Reporter: Ed Roberts
Assignee: Thomas Diesler
I am able to recreate a bundle resolution problem that gives very little help in where the cause lies.
We deploy a set of Spring 3.1.1.RELEASE bundles in the bundles directory structure, exposed through the standalone.xml capabilities. Separately, a set of bundles are located in the deployments folder, and they include/use some Spring 3.0.7.RELEASE; e.g. beans and core. The reason for the duplication is because a particular LDAP bundle does not work with the later spring bundles. When I deploy the spring-security-ldap-3.1.1.RELEASE.jar in the deployments folder, I get the following WARNING in the console/log file
{code}
2012-11-27 16:24:13,808 WARN [org.jboss.as.osgi](MSC service thread 1-5) JBAS011910: Cannot resolve requirements: []
{code}
The cause of the issue was located during a debug session, to be
{code}
Chain 1:
org.springframework.security.ldap [HostBundleRevision[org.springframework.security.ldap:3.1.1.RELEASE]]
import: null
|
export: osgi.wiring.package=org.springframework.beans
org.springframework.beans [HostBundleRevision[org.springframework.beans:3.0.7.RELEASE]]
Chain 2:
org.springframework.security.ldap [HostBundleRevision[org.springframework.security.ldap:3.1.1.RELEASE]]
import: null
|
export: osgi.wiring.package=org.springframework.context.support; uses:=org.springframework.beans
org.springframework.context [HostBundleRevision[org.springframework.context:3.1.1.RELEASE]]
import: null
|
export: osgi.wiring.package=org.springframework.beans
org.springframework.beans [HostBundleRevision[org.springframework.beans:3.1.1.RELEASE]]
{code}
It seems that when there are multiple providers of a requirement, the requiring bundle is deemed invalid. That doesn't seem correct. Should it not just choose the first valid provider ? Either way, when the Unresolved Bundles are empty in BundleResolveProcessor, the details of the multiple providers should at least be logged as an ERROR as it prevents the bundle from being successfully resolved.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6046) Logging indicates "missing dependency" not the cause of the error.
by Paul Hinds (JIRA)
Paul Hinds created AS7-6046:
-------------------------------
Summary: Logging indicates "missing dependency" not the cause of the error.
Key: AS7-6046
URL: https://issues.jboss.org/browse/AS7-6046
Project: Application Server 7
Issue Type: Feature Request
Components: Logging
Affects Versions: 7.1.3.Final (EAP)
Reporter: Paul Hinds
Assignee: James Perkins
Priority: Minor
If the Data sources config is incorrect so that the <driver> element does not match an existing driver, the error message is cryptic.
JBAS014775: New missing/unsatisfied dependencies:
service jboss.jdbc-driver.db2xa (missing) dependents: [service jboss.data-source.java:jboss/datasources/myDS]
I would expect a log message at ERROR level, there is no error message while other data sources are loaded.
Missing dependencies is printed on a line with no error level and the text of the message does not relate to the XML.
I would expect the error message to indicate something about where to fix the error.
e.g an XPath
subsystem[xmlns="urn:jboss:domain:datasources:1.0"]/datasources/datasource/driver.
or some text that indicates the <driver> element is the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-5700) WSBAParticipantCompletionTestCase XTS integration test fails intermittently
by Paul Robinson (JIRA)
Paul Robinson created AS7-5700:
----------------------------------
Summary: WSBAParticipantCompletionTestCase XTS integration test fails intermittently
Key: AS7-5700
URL: https://issues.jboss.org/browse/AS7-5700
Project: Application Server 7
Issue Type: Bug
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Priority: Minor
Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
When a WSBA participant employs the ParticipantCompletion protocol, it is the responsibility of the participant to notify the coordinator when it has completed its work. This notification is asynchronous.
In the 'WSBAParticipantCompletionTestCase' test, the client invokes the participant's web service who notifies completion just before returning from the invocation. The client then sends a message to the coordinator requesting to close (complete) the activity.
As the "complete" message is asynchronous, we now have a race. If the Client's close message is processed by the coordinator before the participant's "complete" message, then the coordinator cancels the BA as not all participants have completed. This results in the client receiving a TransactionRolledBackException and the completed participant is (eventually) compensated. The outcome is atomic, but a BA that would have otherwise succeeded, is unsuccessful.
In reality we only expect this scenario to happen in the rather artificial scenario where all parties (client, coordinator and participants) are on the same server. It also only seems to happen on very slow machines. Therefore, it's fine to fix the test to prevent this scenario from arising, rather than to somehow change the protocol (without breaking the WS-BA standard) to prevent it.
We have two options, that I can see to fix the test:
1) Byteman Rendezvous. Here we would introduce a dependency on Byteman and write a script that delays the client's close message until all participants' 'complete' messages have been acknowledged by the coordinator. This is probably an over-engineered solution as we would be introducing Byteman, to these tests, for this single case.
2) We add a Thread.sleep(10000) to the test, just before the client sends the 'cloe' message to the coordinator. This is what we did to the XTS tests in the JBossTS project as a stop-gap until we decided how to do it "properly".
I suggest we go with 2) as it is the simplest solution. The extra time added to the test is just 20s as there are only two tests affected by this. In the future, when we have more tests we should reduce this sleep period or consider using another solution (such as Byteman), in order to keep the test duration acceptable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6049) Where security services in domain management have a dedicated interface provide a ServiceName factory.
by Darran Lofthouse (JIRA)
Darran Lofthouse created AS7-6049:
-------------------------------------
Summary: Where security services in domain management have a dedicated interface provide a ServiceName factory.
Key: AS7-6049
URL: https://issues.jboss.org/browse/AS7-6049
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.2.0.Alpha1
Update each of the interfaces with a factory for generating the service name.
{code}
public static class ServiceNameFactory {
public ServiceName createServiceName(final String realmName) {
return null;
}
}
{code}
Strictly speaking these are not currently expected to be used outside the AS codebase but should they be used outside of the domain-management module this will be the recommended way to generate the service names.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-4782) NoSuchMethodError: org.jboss.logmanager.LogContext.getLoggerIfExists
by Juergen Zimmermann (JIRA)
Juergen Zimmermann created AS7-4782:
---------------------------------------
Summary: NoSuchMethodError: org.jboss.logmanager.LogContext.getLoggerIfExists
Key: AS7-4782
URL: https://issues.jboss.org/browse/AS7-4782
Project: Application Server 7
Issue Type: Bug
Components: Logging
Affects Versions: 7.1.2.Final (EAP)
Environment: Compilation: JBossAS 7.1.2.Final checked out from github.com and compiled with JDK 7u4 32-Bit on Win7 64-Bit.
Runtime: JDK 7u4 64-Bit on same Windows box.
Reporter: Juergen Zimmermann
Assignee: James Perkins
I'm running just a simple test which was working fine on JBossAS 7.1.1. Now on 7.1.2 (see description in the Environment section) I'm getting this stacktrace:
java.lang.RuntimeException: Could not create a new instance of class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor see cause.
at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:170)
at org.jboss.arquillian.test.spi.TestRunnerAdaptorBuilder.build(TestRunnerAdaptorBuilder.java:52)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:93)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:166)
... 14 more
Caused by: java.lang.RuntimeException: Could not create a new instance of class org.jboss.arquillian.core.impl.ManagerImpl see cause.
at org.jboss.arquillian.core.spi.SecurityActions.newInstance(SecurityActions.java:157)
at org.jboss.arquillian.core.spi.ManagerBuilder.create(ManagerBuilder.java:77)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.<init>(EventTestRunnerAdaptor.java:55)
... 19 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.jboss.arquillian.core.spi.SecurityActions.newInstance(SecurityActions.java:153)
... 21 more
Caused by: java.lang.NoSuchMethodError: org.jboss.logmanager.LogContext.getLoggerIfExists(Ljava/lang/String;)Lorg/jboss/logmanager/Logger;
at org.apache.log4j.JBossLogManagerFacade.updateParents(JBossLogManagerFacade.java:197)
at org.apache.log4j.JBossLogManagerFacade.getLogger(JBossLogManagerFacade.java:145)
at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:130)
at org.apache.log4j.Hierarchy.getLogger(Hierarchy.java:125)
at org.apache.log4j.LogManager.getLogger(LogManager.java:57)
at org.apache.log4j.Logger.getLogger(Logger.java:35)
at org.jboss.logging.Log4jLogger.<init>(Log4jLogger.java:35)
at org.jboss.logging.Log4jLoggerProvider.getLogger(Log4jLoggerProvider.java:33)
at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:37)
at org.jboss.logging.LoggerProviders.<clinit>(LoggerProviders.java:32)
at org.jboss.logging.Logger.getLogger(Logger.java:2163)
at org.jboss.logging.Logger.getLogger(Logger.java:2188)
at org.jboss.as.arquillian.protocol.jmx.ArquillianServiceDeployer.<clinit>(ArquillianServiceDeployer.java:47)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at org.jboss.arquillian.core.impl.Reflections.createInstance(Reflections.java:128)
at org.jboss.arquillian.core.impl.ManagerImpl.createExtensions(ManagerImpl.java:410)
at org.jboss.arquillian.core.impl.ManagerImpl.fireProcessing(ManagerImpl.java:345)
at org.jboss.arquillian.core.impl.ManagerImpl.<init>(ManagerImpl.java:98)
... 26 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months