[JBoss JIRA] (WFLY-1541) UT005013 with RichFaces 5 and the tag <r:push> which uses WebSockets
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1541?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-1541:
--------------------------------------
Do you still get these stack traces in the logs with WF Alpha3?
> UT005013 with RichFaces 5 and the tag <r:push> which uses WebSockets
> --------------------------------------------------------------------
>
> Key: WFLY-1541
> URL: https://issues.jboss.org/browse/WFLY-1541
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
>
> I'm using a WildFly 8.0.0.Alpha2 snapshot with Undertow 1.0.0.Alpha19. The snapshot is configured for Mojarra 2.1.23 instead of 2.2.0 because of the new RichFaces 5.0.0.Alpha1 which still cannot use Mojarra 2.2. During a websocket push via <r:push> I'm getting the stacktrace below. RichFaces itself is using Atmosphere 1.0.13 for WebSockets.
> Log messages when Atmosphere is started:
> {code}
> 09:38:56,670 INFO [org.atmosphere.cpr.AtmosphereFramework] Auto detecting atmosphere handlers /WEB-INF/classes/
> 09:38:56,702 INFO [org.atmosphere.cpr.AtmosphereFramework] Auto detecting WebSocketHandler in /WEB-INF/classes/
> 09:38:56,702 INFO [org.atmosphere.cpr.AtmosphereFramework] Installed WebSocketProtocol org.atmosphere.websocket.protocol.SimpleHttpProtocol
> 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Atmosphere is using async support: org.atmosphere.container.BlockingIOCometSupport running under container: Undertow - 1.0.0.Alpha19
> 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Installed AtmosphereInterceptor Track Message Size Interceptor using |.
> 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Installed Default AtmosphereInterceptor [Android Interceptor Support, SSE Interceptor Support, JSONP Interceptor Support, Atmosphere JavaScript Protocol, Browser disconnection detection, Track Message Size Interceptor using |]. Set org.atmosphere.cpr.AtmosphereInterceptor.disableDefaults in your xml to disable them.
> 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Using BroadcasterCache: org.atmosphere.cache.HeaderBroadcasterCache
> 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Shared ExecutorService supported: true
> 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] HttpSession supported: false
> 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Using BroadcasterFactory: org.atmosphere.cpr.DefaultBroadcasterFactory
> 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Using WebSocketProcessor: org.atmosphere.websocket.DefaultWebSocketProcessor
> 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Using Broadcaster: org.atmosphere.cpr.DefaultBroadcaster
> 09:38:56,718 INFO [org.atmosphere.cpr.AtmosphereFramework] Atmosphere Framework 1.0.13 started.
> {code}
> Stacktrace:
> {code}
> 09:40:44,640 ERROR [io.undertow.request.io] UT005013: An IOException occurred: java.io.IOException: Eine bestehende Verbindung wurde softwaregesteuert
> durch den Hostcomputer abgebrochen
> at sun.nio.ch.SocketDispatcher.write0(Native Method) [rt.jar:1.7.0_21]
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:51) [rt.jar:1.7.0_21]
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:94) [rt.jar:1.7.0_21]
> at sun.nio.ch.IOUtil.write(IOUtil.java:65) [rt.jar:1.7.0_21]
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:450) [rt.jar:1.7.0_21]
> at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:148) [xnio-nio-3.1.0.CR3.jar:3.1.0.CR3]
> at io.undertow.server.HttpResponseConduit.write(HttpResponseConduit.java:476)
> at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:184)
> at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:147) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> at io.undertow.server.HttpServerExchange$WriteDispatchChannel.flush(HttpServerExchange.java:1500)
> at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1298)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1287)
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:47)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> {code}
--
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
[JBoss JIRA] (JGRP-1662) Remove flow control and fragmentation if run on TCP transport
by Bela Ban (JIRA)
Bela Ban created JGRP-1662:
------------------------------
Summary: Remove flow control and fragmentation if run on TCP transport
Key: JGRP-1662
URL: https://issues.jboss.org/browse/JGRP-1662
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.3.4, 3.4
When run with a TCP transport, we don't need MFC and FRAG(2). However, if we remove FRAG2, the bundler at the transport will drop a message if it exceeds max_bundle_size.
Let's therefore bypass message bundling when the transport is TCP (TCP has its own batching).
TODO: measure how this change affects performance on a 4 node cluster. If positive, commit it.
--
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
[JBoss JIRA] (WFLY-1460) WildFly server fails to start with transactions configured to be run with JDBCObject store
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1460?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1460:
-----------------------------------------------
Ondrej Chaloupka <ochaloup(a)redhat.com> made a comment on [bug 971360|https://bugzilla.redhat.com/show_bug.cgi?id=971360]
Yes, I suppose that this should be assigned to Stefano. Just I wasn't sure who will be responsible for the issue in time when I was creating the bz. As Carlo is coordinator I thought being good idea to put the bz on him.
Carlo can I reassigned the bz to Stefano?
The remark about the tech preview concerns the EAP 6.1.0 as the feature was available there but not tested. It was mentioned in doc for customers not being confused. But as was found out now the feature was not usable at all.
> WildFly server fails to start with transactions configured to be run with JDBCObject store
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-1460
> URL: https://issues.jboss.org/browse/WFLY-1460
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.0.0.Alpha1
> Reporter: Ondřej Chaloupka
> Assignee: Stefano Maestri
>
> In case that you configure transactions subsystem for running with JDBCObject store the app server fails to start because of (it seems so) a circular dependency.
> You can expect the exception like:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 52) JBAS014612: Operation ("add") failed - address: ([("subsystem" => "transactions")]): org.jboss.msc.service.CircularDependencyException: Container jboss-as has a circular dependency: [service jboss.txn.ArjunaObjectStoreEnvironment, service jboss.txn.ArjunaRecoveryManager, service jboss.connector.transactionintegration, service jboss.cached-connection-manager, service jboss.data-source.java:jboss/datasources/JDBCObjectDS]
> {code}
> My assumption came from the configuration similar to this:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/JDBCObjectDS" pool-name="JDBCObjectDS" enabled="true" use-ccm="false">
> <connection-url>jdbc:postgresql://postgresserver.com:5432/user1</connection-url>
> <driver-class>org.postgresql.Driver</driver-class>
> <driver>postgresql-9.2-1002.jdbc4.jar</driver>
> <security>
> <user-name>user1</user-name>
> <password>user1</password>
> </security>
> </datasource>
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/JDBCObjectDS" />
> {code}
--
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
[JBoss JIRA] (WFLY-1379) log4j appenders force initialization of the appender/handler on reboot
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1379?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1379:
-----------------------------------------------
James Perkins <jperkins(a)redhat.com> changed the Status of [bug 971190|https://bugzilla.redhat.com/show_bug.cgi?id=971190] from ASSIGNED to POST
> log4j appenders force initialization of the appender/handler on reboot
> ----------------------------------------------------------------------
>
> Key: WFLY-1379
> URL: https://issues.jboss.org/browse/WFLY-1379
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: 8.0.0.Alpha1
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 8.0.0.Alpha2
>
>
> Adding a log4j appender works until the server is rebooted. The difference in the class names, {{org.apache.log4j.SomeAppender}} and manually added {{org.jboss.as.logging.logmanager.Log4jAppenderHandler}}, results in the handler being reconfigured.
> This also hits a bug (LOGMGR-58) in the logmanager where null references are can be retrieved before a full commit is invoked.
> Stack trace:
> {code}
> 10:53:44,909 ERROR [stderr] (Controller Boot Thread) java.lang.NullPointerException
> 10:53:44,909 ERROR [stderr] (Controller Boot Thread) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> 10:53:44,912 ERROR [stderr] (Controller Boot Thread) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:53:44,912 ERROR [stderr] (Controller Boot Thread) at java.lang.reflect.Method.invoke(Method.java:601)
> 10:53:44,915 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:218)
> 10:53:44,915 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:198)
> 10:53:44,916 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:316)
> 10:53:44,916 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:341)
> 10:53:44,916 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:290)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:282)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
> 10:53:44,918 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> 10:53:44,918 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> 10:53:44,918 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:296)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:226)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:342)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:317)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:189)
> 10:53:44,920 ERROR [stderr] (Controller Boot Thread) at java.lang.Thread.run(Thread.java:722)
> 10:53:44,920 ERROR [stderr] (Controller Boot Thread) java.lang.NullPointerException
> 10:53:44,921 ERROR [stderr] (Controller Boot Thread) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> 10:53:44,921 ERROR [stderr] (Controller Boot Thread) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:53:44,922 ERROR [stderr] (Controller Boot Thread) at java.lang.reflect.Method.invoke(Method.java:601)
> 10:53:44,922 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:218)
> 10:53:44,923 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:198)
> 10:53:44,923 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:316)
> 10:53:44,923 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:341)
> 10:53:44,924 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:290)
> 10:53:44,925 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:282)
> 10:53:44,925 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> 10:53:44,926 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
> 10:53:44,926 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
> 10:53:44,926 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> 10:53:44,927 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> 10:53:44,927 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:296)
> 10:53:44,928 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:226)
> 10:53:44,928 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:342)
> 10:53:44,928 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:317)
> 10:53:44,929 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:189)
> 10:53:44,929 ERROR [stderr] (Controller Boot Thread) at java.lang.Thread.run(Thread.java:722)
> 10:53:44,930 ERROR [stderr] (Controller Boot Thread) java.lang.NullPointerException
> 10:53:44,931 ERROR [stderr] (Controller Boot Thread) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> 10:53:44,931 ERROR [stderr] (Controller Boot Thread) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:53:44,931 ERROR [stderr] (Controller Boot Thread) at java.lang.reflect.Method.invoke(Method.java:601)
> 10:53:44,932 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:218)
> 10:53:44,932 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:198)
> 10:53:44,933 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:316)
> 10:53:44,933 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:341)
> 10:53:44,933 ERROR [stderr] (Controller Boot Thread) at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:290)
> 10:53:44,934 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:282)
> 10:53:44,934 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> 10:53:44,934 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
> 10:53:44,935 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
> 10:53:44,935 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> 10:53:44,936 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> 10:53:44,936 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:296)
> 10:53:44,937 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:226)
> 10:53:44,937 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:342)
> 10:53:44,937 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.server.ServerService.boot(ServerService.java:317)
> 10:53:44,938 ERROR [stderr] (Controller Boot Thread) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:189)
> 10:53:44,938 ERROR [stderr] (Controller Boot Thread) at java.lang.Thread.run(Thread.java:722)
> {code}
--
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
[JBoss JIRA] (JBWEB-276) Using non-blocking thread pool causes excessive RejectedExecutionExceptions to be logged
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWEB-276?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBWEB-276:
-----------------------------------------------
James Livingston <jlivings(a)redhat.com> made a comment on [bug 985191|https://bugzilla.redhat.com/show_bug.cgi?id=985191]
For the default blocking thread pools, a RejectedExecutionException means a serious problem occurred, yes.
If you switch the web container over to using a non-blocking thread pool however, so that it drops requests rather than blocking, it is expected that you would receive these.
Currently if you want to make JBoss drop web requests when there are too many, it writes a large number of these errors out into the log, which would have performance implications reducing the usefulness of dropping request under excessive load.
If you don't want to hide the message since it is serious for blocking thread pools, is there an alternative which would let people using non-blocking thread pools hide it? It would be possible to move it to a different logging category, which could be turned off, but adding a new logging category for one message seems excessive.
> Using non-blocking thread pool causes excessive RejectedExecutionExceptions to be logged
> ----------------------------------------------------------------------------------------
>
> Key: JBWEB-276
> URL: https://issues.jboss.org/browse/JBWEB-276
> Project: JBoss Web
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.2.0.Beta1
> Reporter: James Livingston
> Assignee: Remy Maucherat
> Attachments: JBWEB-276-1.patch
>
>
> When a finite-queue thread pool is used to process web requests, the queue being full can either block or drop the request. If you use a pool which drops requests, a RejectedExecutionException is thrown.
> Currently JIoEndpoint catches that exception the same as other ones such as being unable to create threads. When using a non-blocking pool, the task being rejected is not a critical error like other exceptions so should not be logged at ERROR level.
> Under excessive load, these exception will be continuously generated as requests are dropped, which cases a large amount of logging. Setting it to DEBUG level would stop that, but it would hide the potentially useful messages by default.
--
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
[JBoss JIRA] (WFLY-1269) single jdbc driver deployed inside ear takes name of ear
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-1269?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-1269:
------------------------------------
Paul, if this is broken again against WildFly release, could you please create a forum thread with the relevant details and if possible a reproducible application. The forum is here https://community.jboss.org/en/wildfly?view=discussions. If it turns out to be a bug, we'll open a new JIRA.
> single jdbc driver deployed inside ear takes name of ear
> --------------------------------------------------------
>
> Key: WFLY-1269
> URL: https://issues.jboss.org/browse/WFLY-1269
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Affects Versions: 8.0.0.Alpha1
> Reporter: Tom Eicher
> Assignee: Stefano Maestri
> Fix For: 8.0.0.Alpha1
>
>
> We need to always give service name for jdbdriver as
> {code}
> deploymentUnit.getName() + "_" + driverClassName + "_" + majorVersion +"_" + minorVersion
> {code}
> even if thre is only one driver in the deployment unit. Current behavior is to give just deploymentUnit name in case of only one driver in. The changes makes more clear/readable driver names.
> Original description was:
> Including a JDBC driver, in this case PostgreSQL, in an ear like
> {code}
> myapp.ear:
> lib/postgresql-9.1-901.jdbc4.jar
> {code}
> does deploy the driver:
> {code}
> 23:37:28,118 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010404: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.1)
> {code}
> however the service name is not {{postgresql_9_1_901_jdbc4_jar}} as expected,
> but it's {{myapp_ear}}.
> (Seen in admin console, and this is the only value accepted in my -ds.xml file.)
> 1. JDBC driver service should pick name of innermost jar, not of containing ear
> 2. driver name (as to be used in datasource definition) should be logged with the log message above.
--
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