November 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JASSIST-44) Maven profiles for tools.jar should take account of Mac OS

by Martin Burger (JIRA)

Maven profiles for tools.jar should take account of Mac OS ---------------------------------------------------------- Key: JASSIST-44 URL: http://jira.jboss.com/jira/browse/JASSIST-44 Project: Javassist Issue Type: Bug Environment: Maven version: 2.0.8 Java version: 1.5.0_13 OS name: "mac os x" version: "10.4.11" arch: "i386" Family: "unix" Reporter: Martin Burger Assigned To: Shigeru Chiba The pom.xml uses different profiles to add the tools.jar to the dependencies. However, it is already included in the runtime for Mac OS X and some free JDKs and does not exist as a separate file 'tools.jar'. See: http://maven.apache.org/general.html#tools-jar-dependency As soon as http://jira.codehaus.org/browse/MNG-3106 gets fixed, activation should look like the following example: <activation> <jdk>1.6</jdk> <property> <name>java.vendor</name> <value>Sun Microsystems Inc.</value> </property> </activation> In the meantime <profiles> <profile> <id>tools.jar</id> <activation> <property> <name>java.vendor</name> <value>Sun Microsystems Inc.</value> </property> </activation> <dependencies> <dependency> <groupId>com.sun</groupId> <artifactId>tools</artifactId> <version>1.6</version> <scope>system</scope> <optional>true</optional> <systemPath>${java.home}/../lib/tools.jar</systemPath> </dependency> </dependencies> </profile> </profiles> should do the job. It could be a permanent solution because the different profiles differ only in the version element. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
5
0 / 0

[JBoss JIRA] Created: (JASSIST-106) Maven build doesn't work on Mac OS X

by Pete Muir (JIRA)

Maven build doesn't work on Mac OS X ------------------------------------ Key: JASSIST-106 URL: https://jira.jboss.org/jira/browse/JASSIST-106 Project: Javassist Issue Type: Task Affects Versions: 3.11.0.GA Reporter: Pete Muir Assignee: Shigeru Chiba It references tools.jar which doesn't exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JASSIST-96) Publish javassist to Maven central

by Pete Muir (JIRA)

Publish javassist to Maven central ---------------------------------- Key: JASSIST-96 URL: https://jira.jboss.org/jira/browse/JASSIST-96 Project: Javassist Issue Type: Task Reporter: Pete Muir It would be nice if Javassist were published to Maven central regularly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

4
15
0 / 0

[JBoss JIRA] Created: (JBAS-4526) JBossMQ UIL2 Read/Write Tasks should not be doing initialization

by Adrian Brock (JIRA)

JBossMQ UIL2 Read/Write Tasks should not be doing initialization ---------------------------------------------------------------- Key: JBAS-4526 URL: http://jira.jboss.com/jira/browse/JBAS-4526 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: JMS service Affects Versions: JBossAS-4.2.1.GA Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.GA, JBossAS-4.2.2.CR1 The JBossMQ UIL2 Read/Write tasks both do their stream initialization when each thread starts. This code needs changing such that the streams are allocated before started the threads. Only if all resources can be succesfully allocated should we start the threads. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

3
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1732) Pooling strategy and configuration information needed at runtime

by Galder Zamarreno (JIRA)

Pooling strategy and configuration information needed at runtime ---------------------------------------------------------------- Key: EJBTHREE-1732 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1732 Project: EJB 3.0 Issue Type: Bug Components: ejb3 Affects Versions: AS 4.2.3.GA Reporter: Galder Zamarreno There needs to be a way at runtime to see what pooling strategy (including configuration options) an EJB3 bean is using. Currently, the only way to see this is by enabling TRACE on org.jboss.ejb3 and making an invocation to that EJB3 bean. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2197) Two WARs containing no-local-view EJBs with same name fails to deploy

by Nicklas Karlsson (JIRA)

Two WARs containing no-local-view EJBs with same name fails to deploy --------------------------------------------------------------------- Key: EJBTHREE-2197 URL: https://jira.jboss.org/browse/EJBTHREE-2197 Project: EJB 3.0 Issue Type: Bug Reporter: Nicklas Karlsson Both try to bind to the same JNDI name causing the second WAR to fail deployment: 13:49:05,276 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=vfs:///C:/Java/AS/jboss-6.0.0-SNAPSHOT/server/default/deploy/LTK.war$Kirjautumistoiminnot state=Create: javax.naming.NameAlreadyBoundException: no-interface at org.jnp.server.NamingServer.bind(NamingServer.java:209) [:5.0.5.Final] at org.jnp.server.NamingServer.bind(NamingServer.java:167) [:5.0.5.Final] at org.jnp.interfaces.NamingContext.bind(NamingContext.java:652) [:5.0.5.Final] at org.jnp.interfaces.NamingContext.bind(NamingContext.java:613) [:5.0.5.Final] at org.jboss.util.naming.Util.bind(Util.java:105) [jboss-common-core.jar:2.2.17.GA] at org.jboss.util.naming.Util.bind(Util.java:91) [jboss-common-core.jar:2.2.17.GA] at org.jboss.ejb3.nointerface.impl.jndi.SessionAwareNoInterfaceViewJNDIBinder.bindNoInterfaceView(SessionAwareNoInterfaceViewJNDIBinder.java:118) [:] at org.jboss.ejb3.nointerface.impl.jndi.NoInterfaceViewJNDIBinderFacade.onStart(NoInterfaceViewJNDIBinderFacade.java:127) [:] at sun.reflect.GeneratedMethodAccessor336.invoke(Unknown Source) [:1.6.0_20] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_20] at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_20] at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:60) [jboss-reflect.jar:2.2.0.Alpha9] at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:168) [jboss-reflect.jar:2.2.0.Alpha9] at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) [jboss-reflect.jar:2.2.0.Alpha9] at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257) [jboss-kernel.jar:2.2.0.Alpha10] at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47) [jboss-kernel.jar:2.2.0.Alpha10] at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:125) [jboss-kernel.jar:2.2.0.Alpha10] at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) [jboss-kernel.jar:2.2.0.Alpha10] at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:202) [jboss-kernel.jar:2.2.0.Alpha10] at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.Alpha10] at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:894) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:641) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:182) [:2.2.0.Alpha8] at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:58) [:2.2.0.Alpha8] at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.Alpha8] at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.Alpha8] at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha8] at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.Alpha8] at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.Alpha8] at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1571) [:2.2.0.Alpha8] at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.Alpha8] at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.Alpha10] at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.Alpha8] at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.Alpha8] at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.Alpha8] at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0-SNAPSHOT] at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:130) [:0.1.0.Alpha1] at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.1.0.Alpha1] at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.1.0.Alpha1] at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:59) [:0.1.0.Alpha1] at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.1.0.Alpha1] at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:94) [:0.1.0.Alpha1] at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.1.0.Alpha1] at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.1.0.Alpha1] at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.1.0.Alpha1] at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.1.0.Alpha1] at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.1.0.Alpha1] at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.1.0.Alpha1] at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.1.0.Alpha1] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_20] at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_20] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_20] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_20] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) [:1.6.0_20] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) [:1.6.0_20] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20] at java.lang.Thread.run(Thread.java:619) [:1.6.0_20] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

3
15
0 / 0

[JBoss JIRA] Created: (JBAS-7994) Clean up quartz messages in AS startup log

by Paul Gier (JIRA)

Clean up quartz messages in AS startup log ------------------------------------------ Key: JBAS-7994 URL: https://jira.jboss.org/jira/browse/JBAS-7994 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Paul Gier Assignee: Paul Gier Fix For: 6.0.0.CR1 The recent updates to quartz have added more noise to the console log. These messages should be written only to the log file and not the console. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-7674) Windows file locking problem with the data/jnp-service.url file

by Brian Stansberry (JIRA)

Windows file locking problem with the data/jnp-service.url file --------------------------------------------------------------- Key: JBAS-7674 URL: https://jira.jboss.org/jira/browse/JBAS-7674 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Management services Affects Versions: JBossAS-6.0.0.M1, JBossAS-5.1.0.GA Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: JBossAS-6.0.0.M2 In some circumstances, windows is reporting the AS is holding a lock on the data/jnp-service.url file when it isn't running. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

5
10
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1456) Messages stuck in being-delivered state in cluster

by Justin Bertram (JIRA)

Messages stuck in being-delivered state in cluster -------------------------------------------------- Key: JBMESSAGING-1456 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1456 Project: JBoss Messaging Issue Type: Bug Reporter: Justin Bertram Assignee: Tim Fox Priority: Critical Messages become "stuck" in being-delivered state when clients use a clustered XA connection factory in a cluster of at least 2 nodes. JBoss setup: -2 nodes of JBoss EAP 4.3 CP02 -commented out "ClusterPullConnectionFactory" in messaging-service.xml to prevent message redistribution and eliminate the "message suckers" as the potential culprit -MySQL backend using the default mysql-persistence-service.xml (from <JBOSS_HOME>/docs/examples/jms) Client setup: -both nodes have a client which is a separate process (i.e. not inside JBoss) -clients are Spring based -one client produces and consumes, the other client just consumes -both clients use the ClusteredXAConnectionFactory from the default connection-factories-service.xml -both clients publish to and consume from "queue/testDistributedQueue" -clients are configured to send persistent messages, use AUTO_ACKNOWLEDGE, and transacted sessions Symptoms of the issue: -when running the clients I watch the JMX-Console for the "queue/testDistributedQueue" -as the consumers pull messages off the queue I can see the MessageCount and DeliveringCount go to 0 every so often -after a period of time (usually a few hours) the MessageCount and DeliveringCount never go back to 0 -I "kill" the clients and wait for the DeliveringCount to go to 0, but it never does -after the clients are killed the ConsumerCount for the queue will drop, but never to 0 when messages are "stuck" -a thread dump reveals at least one JBM server session that is apparently stuck (it never goes away) - ostensibly this is the consumer that is showing in the JMX-Console for "queue/testDistributedQueue" -a "killall -3 java" doesn't produce anything from the clients so I know their dead -nothing is in any DLQ or expiry queue -the database contains as many rows in the JBM_MSG and JBM_MSG_REF tables as the DeliveringCount in the JMX-Console -rebooting the node with the stuck messages frees the messages to be consumed (i.e. un-sticks them) Other notes: -nothing else is happening on either node but running the client and running JBoss -this only appears to happen when a clustered connection factory is used. I tested using a normal connection factory and after 24 hours couldn't reproduce a stuck message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

11
102
0 / 0

[JBoss JIRA] Created: (HIBERNATE-120) Hibernate maps type "timestamp" to Mysql's type "datetime" not "timestamp"

by zhou yanming (JIRA)

Hibernate maps type "timestamp" to Mysql's type "datetime" not "timestamp" -------------------------------------------------------------------------- Key: HIBERNATE-120 URL: https://jira.jboss.org/jira/browse/HIBERNATE-120 Project: Hibernate Integration Issue Type: Bug Reporter: zhou yanming Assignee: Steve Ebersole Priority: Critical datetime will trim millisecond record.setLastModified(new Date(1250053078708)); session.save(record); .... record = session.load(record.getId()); System.out.println(record.getLastModified()); // here is 125005307000 not expected 1250053078708 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 5 months

3
4
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 November 2010