[JBoss JIRA] (JASSIST-217) javassist does not work with java8 and lambda
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JASSIST-217?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on JASSIST-217:
-------------------------------------------------
Mikolaj Izdebski <mizdebsk(a)redhat.com> changed the Status of [bug 1089975|https://bugzilla.redhat.com/show_bug.cgi?id=1089975] from ASSIGNED to MODIFIED
> javassist does not work with java8 and lambda
> ---------------------------------------------
>
> Key: JASSIST-217
> URL: https://issues.jboss.org/browse/JASSIST-217
> Project: Javassist
> Issue Type: Feature Request
> Affects Versions: 3.18.1-GA
> Environment: weld+tomcat
> Reporter: Sachin Dole
> Assignee: Shigeru Chiba
> Priority: Blocker
> Labels: java8, lambda
>
> I upgraded my tomcat webapp project which uses weld CDI to use JDK8 and wrote code using the new java.util Streams and lambda constructs. weld failed to start up because javassist could not deal with lambda. the work around is to use java7 style explicit classes instead of lambda - that works just like expected.
> I REALLY like java 8's stream and related collections features and want to use it. lambda constructs are also good because these reduce lines of code.
> Is there a plan to fix support for java8?
> If its needed, I will be happy to produce a project that fails in java8. however, it is totally evident in the simplest of use cases as long as you use lambda.
--
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
11 years, 8 months
[JBoss JIRA] (WFLY-3292) EE Resource Definition Code Rework
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-3292?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-3292:
---------------------------------------
[~jesper.pedersen] [~jmesnil] [~ctomc] [~swd847] I guess all of you have been involved with EE resource definitions before, thus I invite you all to have a look to changes in your code.
> EE Resource Definition Code Rework
> ----------------------------------
>
> Key: WFLY-3292
> URL: https://issues.jboss.org/browse/WFLY-3292
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: EE, JCA, JMS, Mail, Naming
> Reporter: Eduardo Martins
> Assignee: Eduardo Martins
>
> This enhancement task provides a refresh/cleanup of all code related with EE resource definitions (as defined by EE.5.18).
> A major goal is to sync the logic that works out the deployment of all resource definitions (datasource, connection factory, administered objects, mail session, jms destination and jms connection factory), introducing specific abstract processors for both descriptors and annotations. These processors should continue to use the same functionality under the hood, i.e. feed BindingConfigurations to the same collections as any resource, but may allow in the future an easy split of deployment phase to install the related bindings, which should help the logic of dependent services.
> Another goal is to fix or provide missing functionality, such as support for <connection-factory /> and <administired-object />.
--
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
11 years, 8 months
[JBoss JIRA] (LOGMGR-89) LogContext's root logger is not created with a strong child hash map when strong=true
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-89?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on LOGMGR-89:
-----------------------------------------------
Nikoleta Ziakova <nziakova(a)redhat.com> changed the Status of [bug 1052198|https://bugzilla.redhat.com/show_bug.cgi?id=1052198] from ON_QA to VERIFIED
> LogContext's root logger is not created with a strong child hash map when strong=true
> -------------------------------------------------------------------------------------
>
> Key: LOGMGR-89
> URL: https://issues.jboss.org/browse/LOGMGR-89
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: This issue happens on 32-bit JVMs, and I can reproduce it on JDK 6 (64-bit)
> Reporter: Kyle Lape
> Assignee: David Lloyd
> Fix For: 1.2.3.GA, 1.3.3.Final, 1.4.4.Final, 1.5.2.Final, 2.0.0.Beta1
>
>
> When deploying an application in EAP 6 that has a log4j.xml that is deployed by the logging subsystem, it seems that the LogContext is somehow losing a reference to a custom logger, causing all configuration for that logger to be lost.
> Given this configuration
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="true">
> <appender name="SAMPLE_APP" class="org.apache.log4j.RollingFileAppender">
> <param name="File" value="${jboss.server.log.dir}/SampleApp.log"/>
> <param name="MaxFileSize" value="2MB"/>
> <param name="MaxBackupIndex" value="5"/>
> <param name="Append" value="true"/>
> <layout class="org.apache.log4j.PatternLayout">
> <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/>
> </layout>
> </appender>
> <appender name="SAMPLE_APP_MDB" class="org.apache.log4j.RollingFileAppender">
> <param name="File" value="${jboss.server.log.dir}/SampleApp-MDB.log"/>
> <param name="MaxFileSize" value="2MB"/>
> <param name="MaxBackupIndex" value="5"/>
> <param name="Append" value="true"/>
> <layout class="org.apache.log4j.PatternLayout">
> <param name="ConversionPattern" value="%d %c [%t] %-5p - %m%n"/>
> </layout>
> </appender>
> <logger name="com.redhat" additivity="false">
> <level value="TRACE"/>
> <appender-ref ref="SAMPLE_APP_MDB"/>
> </logger>
> <root>
> <priority value="TRACE"/>
> <appender-ref ref="SAMPLE_APP"/>
> </root>
> </log4j:configuration>
> {code}
> Every log message ends up in {{SAMPLE_APP}}, regardless of which logger was used. One message like this is also printed to the log:
> {noformat}
> 11:33:00,110 INFO [stdout] (Finalizer) log4j: Finalizing appender named [SAMPLE_APP_MDB].
> {noformat}
--
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
11 years, 8 months
[JBoss JIRA] (JBMESSAGING-1750) Allow arbitrary SQL statements for JDBCPersistenceManagerService
by Justin Bertram (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1750?page=com.atlassian.jira.... ]
Justin Bertram resolved JBMESSAGING-1750.
-----------------------------------------
Resolution: Won't Fix
> Allow arbitrary SQL statements for JDBCPersistenceManagerService
> ----------------------------------------------------------------
>
> Key: JBMESSAGING-1750
> URL: https://issues.jboss.org/browse/JBMESSAGING-1750
> Project: JBoss Messaging
> Issue Type: Feature Request
> Components: Configuration and Management
> Affects Versions: 1.4.0.SP3.CP08
> Reporter: Justin Bertram
> Assignee: Yong Hao Gao
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12
>
>
> Allow arbitrary SQL statements in the SQLProperties field of org.jboss.messaging.core.jmx.JDBCPersistenceManagerService which will be executed just like all the others (e.g. if CreateTablesOnStartup = "true"). I imagine the statements will need to be named according to some pattern (e.g. "CREATE_*").
> This functionality will allow greater flexibility for our RDBMS support (e.g. a user could configure support for Oracle TimesTen).
--
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
11 years, 8 months
[JBoss JIRA] (JBMESSAGING-1731) Expose the JBoss Messaging Cluster partition in JMX
by Justin Bertram (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1731?page=com.atlassian.jira.... ]
Justin Bertram resolved JBMESSAGING-1731.
-----------------------------------------
Resolution: Out of Date
> Expose the JBoss Messaging Cluster partition in JMX
> ---------------------------------------------------
>
> Key: JBMESSAGING-1731
> URL: https://issues.jboss.org/browse/JBMESSAGING-1731
> Project: JBoss Messaging
> Issue Type: Feature Request
> Components: Messaging Core
> Affects Versions: 1.4.4.GA
> Reporter: Brad Maxwell
> Assignee: Yong Hao Gao
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12
>
>
> Background:
> I have had a request wanting access to the members of the JBoss Messaging Cluster so that they can configure the Recovery plugin without having to hard code hosts in the configuration file. With the JBoss Messaging Cluster Partition in JMX they would be able to get an accurate list of the members in the Messaging cluster.
--
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
11 years, 8 months
[JBoss JIRA] (JBMESSAGING-1794) SecurityStore not applied correctly
by Justin Bertram (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1794?page=com.atlassian.jira.... ]
Justin Bertram resolved JBMESSAGING-1794.
-----------------------------------------
Resolution: Rejected
> SecurityStore not applied correctly
> -----------------------------------
>
> Key: JBMESSAGING-1794
> URL: https://issues.jboss.org/browse/JBMESSAGING-1794
> Project: JBoss Messaging
> Issue Type: Feature Request
> Components: JMS Security
> Affects Versions: 1.4.6.GA
> Reporter: Justin Bertram
> Assignee: Yong Hao Gao
> Fix For: 1.4.8.SP12
>
>
> The "SecurityStore" in messaging-jboss-beans.xml doesn't appear to be getting applied correctly. Steps to reproduce:
> 1) Unzip a fresh copy of JBoss EAP 5
> 2) Change the "suckerPassword" attribute in <JBOSS_HOME>/server/all/deploy/messaging/messaging-jboss-beans.xml
> 3) Activate TRACE logging with this category in <JBOSS_HOME>/server/all/conf/jboss-log4j.xml:
> <category name="org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore">
> <priority value="TRACE"/>
> </category>
> 4) Start the server: <JBOSS_HOME>/bin/run.sh -c all
> 5) This comes up in the log:
> TRACE [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (main) authenticating user JBM.SUCKER
> TRACE [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (main) Authenticating sucker user
> WARN [org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore] (main) WARNING! POTENTIAL SECURITY RISK. It has been detected that the MessageSucker component which sucks messages from one node to another has not had its password changed from the installation default. Please see the JBoss Messaging user guide for instructions on how to do this.
> ERROR [org.jboss.messaging.util.ExceptionUtil] (main) ConnectionFactoryEndpoint[jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory] createFailoverConnectionDelegate [da-yi5epx6g-1-0jhcpx6g-twc79y-100j3]
> javax.jms.JMSSecurityException: User JBM.SUCKER is NOT authenticated
> at org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore.authenticate(JBossASSecurityMetadataStore.java:223)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262)
> at javax.management.StandardMBean.invoke(StandardMBean.java:391)
> at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy99.authenticate(Unknown Source)
> at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegateInternal(ServerConnectionFactoryEndpoint.java:233)
> at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegate(ServerConnectionFactoryEndpoint.java:171)
> at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.org$jboss$jms$server$endpoint$advised$ConnectionFactoryAdvised$createConnectionDelegate$aop(ConnectionFactoryAdvised.java:108)
> at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.createConnectionDelegate(ConnectionFactoryAdvised.java)
> at org.jboss.jms.wireformat.ConnectionFactoryCreateConnectionDelegateRequest.serverInvoke(ConnectionFactoryCreateConnectionDelegateRequest.java:91)
> at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:157)
> at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:897)
> at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
> at org.jboss.remoting.Client.invoke(Client.java:1917)
> at org.jboss.remoting.Client.invoke(Client.java:768)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$createConnectionDelegate$aop(ClientConnectionFactoryDelegate.java:178)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
> at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:80)
> at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect_z_handleCreateConnectionDelegate_15295742.invoke(StateCreationAspect_z_handleCreateConnectionDelegate_15295742.java)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
> at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
> at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
> at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager$ConnectionInfo.start(ClusterConnectionManager.java:669)
> at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager.ensureAllConnectionsCreated(ClusterConnectionManager.java:419)
> at org.jboss.messaging.core.impl.clusterconnection.ClusterConnectionManager.notify(ClusterConnectionManager.java:241)
> at org.jboss.messaging.core.impl.DefaultClusterNotifier.sendNotification(DefaultClusterNotifier.java:72)
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.putReplicantLocally(MessagingPostOffice.java:1245)
> at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.put(MessagingPostOffice.java:1525)
> at org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper.registerConnectionFactory(ConnectionFactoryJNDIMapper.java:252)
> at org.jboss.jms.server.connectionfactory.ConnectionFactory.startService(ConnectionFactory.java:206)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
> at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:269)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
> at $Proxy38.start(Unknown Source)
> at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
> at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
> at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
> at org.jboss.system.ServiceController.start(ServiceController.java:460)
> at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
> at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
> at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
> at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
> at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
> at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099)
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823)
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
> at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782)
> at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
> at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
> at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
> at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
> at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:403)
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1633)
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083)
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775)
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
> at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:308)
> at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:256)
> at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
> at org.jboss.Main.boot(Main.java:221)
> at org.jboss.Main$1.run(Main.java:556)
> at java.lang.Thread.run(Thread.java:619)
> It appears that org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint is creating the connection with the password from messaging-jboss-beans.xml, but org.jboss.jms.server.jbosssx.JBossASSecurityMetadataStore is authenticating it with the information from messaging-service.xml (which uses the default password since "SuckerPassword" is commented out).
--
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
11 years, 8 months
[JBoss JIRA] (JBMESSAGING-1287) SOA-P test suite failures
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1287?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1287:
--------------------------------------
Fix Version/s: 1.4.8.SP12
(was: 1.4.8.SP11)
> SOA-P test suite failures
> -------------------------
>
> Key: JBMESSAGING-1287
> URL: https://issues.jboss.org/browse/JBMESSAGING-1287
> Project: JBoss Messaging
> Issue Type: Bug
> Affects Versions: 1.4.0.SP3_CP01
> Reporter: Aleksandar Kostadinov
> Assignee: Yong Hao Gao
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12
>
>
> I'm running the JBM test suite against the binaries in the SOA-P Platform 4.2 CP01. I see 4 failures.
> * TEST-org.jboss.test.messaging.jms.bridge.BridgeTest-Remote-bisocket.xml.
> * org.jboss.test.messaging.jms.clustering.MultipleFailoverTest(Clustering).testFailoverFloodTwoServers
> * org.jboss.test.messaging.jms.clustering.NoFailoverTest(Clustering).testCrashNoFailover
> * org.jboss.test.messaging.jms.ManifestTest.testManifestEntries
> Failure details in here http://hudson.qa.jboss.com/hudson/job/jboss-soa-platform-JBM-testsuite/73...
> 3 of the failures are timeout (see console log for BridgeTest). We are running on a 2 CPU DualCore physical machine so system speed should not be an issue.
--
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
11 years, 8 months
[JBoss JIRA] (JBMESSAGING-1491) add support for Ingres RDBMS to JBoss Messaging
by Yong Hao Gao (JIRA)
[ https://issues.jboss.org/browse/JBMESSAGING-1491?page=com.atlassian.jira.... ]
Yong Hao Gao updated JBMESSAGING-1491:
--------------------------------------
Fix Version/s: 1.4.8.SP12
(was: 1.4.8.SP11)
> add support for Ingres RDBMS to JBoss Messaging
> -----------------------------------------------
>
> Key: JBMESSAGING-1491
> URL: https://issues.jboss.org/browse/JBMESSAGING-1491
> Project: JBoss Messaging
> Issue Type: Patch
> Affects Versions: 1.4.0.SP3.CP06, 2.0.0 Beta1, EAP/SOA-P Integration, 1.4.3.GA, Unscheduled, AS 5.0 Integration
> Environment: N/A
> Reporter: murray armfield
> Assignee: Yong Hao Gao
> Priority: Minor
> Fix For: 1.4.0.SP3.CP15, 1.4.8.SP12
>
> Attachments: ingres-persistence-service.newrev.xml, ingres-persistence-service.xml, ingres-persistence-service.xml, ingres.diff, ingresv2.diff
>
> Original Estimate: 30 minutes
> Remaining Estimate: 30 minutes
>
> I've been working on JBoss support on Ingres.
> I've written an ingres-persistence-service.xml file for use with Ingres for inclusion as part of JBoss Messaging
--
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
11 years, 8 months