December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3590) JBoss maps java.math.BigDecimal to numeric(19, 2) for Firebird 1.5 DB. Firebird complains precision must be <= 18.

by knaveofhearts (JIRA)

JBoss maps java.math.BigDecimal to numeric(19,2) for Firebird 1.5 DB. Firebird complains precision must be <= 18. ------------------------------------------------------------------------------------------------------------------ Key: JBAS-3590 URL: http://jira.jboss.com/jira/browse/JBAS-3590 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.0.4.GA Environment: JBossAS-4.0.4.GA, Firebird 1.5, Fedora Core 5 Linux. Reporter: knaveofhearts Assigned To: Bill Burke This is a problem with EJB 3 entity persistence with CMP. I have several classes in which member variables are declared as BigDecimal. The classes all work fine with HSQLDB, which I have been using for rapid development, using the create-drop capability. I tried to switch the backend to Firebird 1.5 by changing the two relevant files (if I recall, persistence.xml and the []-ds.xml file), and managed to remove all the problems (e.g., Fireword reserve words like "role", "user", and "type" that I used as class or attribute names) except for BigDecimal fields. The server log says that BigDecimal is being mapped to numeric(19,2), but the maximum precision for Firebird is 18. If I replace all the BigDecimal fields with double, then my basic DB access tests run okay. I have posted this problem to two JBoss forums (EJB3 and Persistence) and to one Firebird forum (Firebird-Java), but have gotten no replies. If there is an easy fix, I would appreciate learning about it. -- 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

17 years, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (JBXB-92) startElementCreatesObject for simple content with xsd:ID

by Alexey Loubyansky (JIRA)

startElementCreatesObject for simple content with xsd:ID -------------------------------------------------------- Key: JBXB-92 URL: http://jira.jboss.com/jira/browse/JBXB-92 Project: JBoss XML Binding (JBossXB) Issue Type: Feature Request Affects Versions: JBossXB-1.0.0.CR8 Reporter: Alexey Loubyansky Assigned To: Alexey Loubyansky By default, any complex type is supposed to bound to a non-primitive Java type. There should be an exception for commonly complex types with simple content that declare the only xsd:ID attribute since in most cases these types should be treated as primitives. There needs to be a config option to be able to handle such types both ways. package org.jboss.test.xml; public class SimpleContentUnitTestCase extends AbstractJBossXBTest -- 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

17 years, 9 months

1
1
0 / 0

[JBoss JIRA] Created: (JBXB-93) array wrapper pattern in RtElementHandler is too strict

by Alexey Loubyansky (JIRA)

array wrapper pattern in RtElementHandler is too strict ------------------------------------------------------- Key: JBXB-93 URL: http://jira.jboss.com/jira/browse/JBXB-93 Project: JBoss XML Binding (JBossXB) Issue Type: Bug Affects Versions: JBossXB-1.0.0.CR8 Reporter: Alexey Loubyansky Assigned To: Alexey Loubyansky RtElementHandler shouldn't give up after property resolution failed when applying 'array wrapper' pattern. There could be interceptors that take of adding children to the parent overriding handler.setParent(). -- 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

17 years, 9 months

1
1
0 / 0

[JBoss JIRA] Assigned: (JBAOP-37) Before, After, After Throwing support

by Flavia Rainone (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-37?page=all ] Flavia Rainone reassigned JBAOP-37: ----------------------------------- Assignee: Flavia Rainone (was: Flavia Rainone) > Before, After, After Throwing support > ------------------------------------- > > Key: JBAOP-37 > URL: http://jira.jboss.com/jira/browse/JBAOP-37 > Project: JBoss AOP > Issue Type: Feature Request > Affects Versions: 2.0.0.alpha1 > Reporter: Bill Burke > Assigned To: Flavia Rainone > Fix For: 2.0.0.alpha3 > > Original Estimate: 1 week > Remaining Estimate: 1 week > > This should be optimized as well. I've done a non-CVS-checked-in prototype of this. > Feature Details: > To use this feature, one should use the xml tags 'before', 'after' and 'throwing'. > The signature of these advices should take any annotated arguments (annotation rules follow) and 'after' can return a value in order to overwrite/replace the intercepted join point returned value. > Besides, to continue using the advice around, the user should just continue using the 'advice' xml tag. > Around advices should either stick to the signature > Object [advice_name](Invocation invocation) > Or they can now use annotated parameters, as in 'before', 'after' and 'throwing' > The parameters can be annotated with JoinPoint, Invocation, Return, Throwable, Arg, Args, Callee, Caller and Target. > Parameter Annotation Rules: > Except for around default signature, all parameters must be annotated with one of the annotations defined in package org.jboss.aop.advice. We have annotations that are allowed only for specific types of join points, and we have annotations that are allowed only for specific types of advices. > These annotations are allowed depending on the advice type: > - JoinPoint: Before, After, Throwing > - Invocation: Around > - Return: Around, After > - Throwable: Throwing > These annotations are allowed depending on the join point type: > - Callee: call join points > - Caller: call join points > - Target: every non-static join point that is not a call > Finally, we have the mutually exclusive annotations Arg and Args. Both can always be used (but not on the same advice method). The first one must annotate every advice parameter whose value is the value of a join point argument. The second one annotates parameters of type Object[] that must receive all join point arguments values. > Advice Matching Rules > Every Arg parameter is bound to a join point argument of the same type. If there is more than one join point argument with the requested type, then the Arg parameter will be bound to the first join point argument that has not been bound yet. > When there are overloaded advice methods, JBoss AOP will use a priority order to pick the best match. The advice method with the most suitable type of the highest priority annotated parameter type is chosen. > The increasing priority order of arguments is: Arg/Args, Return/Throwable, Target/Callee/Caller , JoinPoint/Invocation. -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBREM-635) Remove misleading error message from HTTPUnMarshaller.

by Ron Sigal (JIRA)

Remove misleading error message from HTTPUnMarshaller. ------------------------------------------------------ Key: JBREM-635 URL: http://jira.jboss.com/jira/browse/JBREM-635 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.2.0.Beta1 (Bluto) In read() the code try { if (isBinaryData(metadata)) return super.read(inputStream, metadata); } catch (Exception e) { log.warn("Can not get Content-Type from header for http unmarshalling."); } can return a warning about content-type even if the exception is thrown by super.read(). -- 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

17 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-647) Initialize Client configuration map to empty HashMap.

by Ron Sigal (JIRA)

Initialize Client configuration map to empty HashMap. ----------------------------------------------------- Key: JBREM-647 URL: http://jira.jboss.com/jira/browse/JBREM-647 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.2.0.Beta1 (Bluto) Currently Client's configuration map is initialized to null by default. Recently I changed Client.getOnewayThreadPool(), so that it looks in configuration for a couple of values, which broke org.jboss.test.remoting.oneway.OnewayInvokerClientTest, which does not initialize configuration. Making sure configuration is always non-null seems like a good idea. -- 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

17 years, 9 months

1
1
0 / 0

[JBoss JIRA] Updated: (EJBTHREE-560) CLONE -Referencing JAR file in persistence.xml - Still a bug and referenced duplicate issue does not exist

by Emmanuel Bernard (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-560?page=all ] Emmanuel Bernard updated EJBTHREE-560: -------------------------------------- Fix Version/s: EJB 3.0 RC10 - FD assigning it to 10, since it worth checking the user patch > CLONE -Referencing JAR file in persistence.xml - Still a bug and referenced duplicate issue does not exist > ---------------------------------------------------------------------------------------------------------- > > Key: EJBTHREE-560 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-560 > Project: EJB 3.0 > Issue Type: Bug > Affects Versions: EJB 3.0 RC1 > Reporter: geoffm74 > Fix For: EJB 3.0 RC10 - FD > > Attachments: PersistenceUnitDeployment.diff > > > I've installed EJB3.0RC1 and the release notes states that now all persistence.xml features are implemented. So I went on trying to use the jar file referencing. > Unfortunately I found that during deployment the only place being searched for this jar file was in JBOSS_HOME/bin. I tried with absolute paths and relative - but it kept hangin on to the bin folder - probably the working folder for jboss launcher. > My jar is bundled with my ear - where should it really be to get the jar reference workin? I think the bin folder is not a proper place.... > Peter -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-3214) Fresh 4.0.4GA/EJB3 install fails to boot because server/default/conf/jboss-service.xml is missing

by Anders Eriksson (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3214?page=comments#action_12348320 ] Anders Eriksson commented on JBAS-3214: --------------------------------------- I saw the same problem using Web Start installer for 4.0.5 GA available here http://labs.jboss.com/portal/jbossas/download . Running 4.0.4 installer did not give the same problem. 4.0.4 seems to work. > Fresh 4.0.4GA/EJB3 install fails to boot because server/default/conf/jboss-service.xml is missing > ------------------------------------------------------------------------------------------------- > > Key: JBAS-3214 > URL: http://jira.jboss.com/jira/browse/JBAS-3214 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Installer > Affects Versions: JBossAS-4.0.4.GA > Environment: OS X 10.4.6, JDK 1.5, JBoss 4.0.4.GA > Reporter: Stefan Arentz > Assigned To: Alex Pinkin > Fix For: JBossAS-4.0.5.CR1 > > > As per instructions in the release notes I installed JBoss 4.0.4GA using: > java -jar jboss-4.0.4.GA-installer.jar -installGroup ejb3 installpath=/Users/stefan/Development/JBoss/JBoss-4.0.4-EJB3 > When I boot this instance it fails with the following message: > % ~/Development/JBoss/JBoss-4.0.4-EJB3 % bin/run.sh > ========================================================================= > JBoss Bootstrap Environment > JBOSS_HOME: /Users/stefan/Development/JBoss/JBoss-4.0.4-EJB3 > JAVA: /usr/bin/java > JAVA_OPTS: -server -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dprogram.name=run.sh > CLASSPATH: /Users/stefan/Development/JBoss/JBoss-4.0.4-EJB3/bin/run.jar:/usr/lib/tools.jar > ========================================================================= > 14:59:12,489 INFO [Server] Starting JBoss (MX MicroKernel)... > 14:59:12,517 INFO [Server] Release ID: JBoss [Zion] 4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605131402) > 14:59:12,555 INFO [Server] Home Dir: /Users/stefan/Development/JBoss/JBoss-4.0.4-EJB3 > 14:59:12,556 INFO [Server] Home URL: file:/Users/stefan/Development/JBoss/JBoss-4.0.4-EJB3/ > 14:59:12,560 INFO [Server] Patch URL: null > 14:59:12,564 INFO [Server] Server Name: default > 14:59:12,565 INFO [Server] Server Home Dir: /Users/stefan/Development/JBoss/JBoss-4.0.4-EJB3/server/default > 14:59:12,566 INFO [Server] Server Home URL: file:/Users/stefan/Development/JBoss/JBoss-4.0.4-EJB3/server/default/ > 14:59:12,567 INFO [Server] Server Log Dir: /Users/stefan/Development/JBoss/JBoss-4.0.4-EJB3/server/default/log > 14:59:12,568 INFO [Server] Server Temp Dir: /Users/stefan/Development/JBoss/JBoss-4.0.4-EJB3/server/default/tmp > 14:59:12,570 INFO [Server] Root Deployment Filename: jboss-service.xml > 14:59:15,654 INFO [ServerInfo] Java version: 1.5.0_06,Apple Computer, Inc. > 14:59:15,657 INFO [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.5.0_06-64,"Apple Computer, Inc." > jndi.properties standardjaws.xml > login-config.xml standardjboss.xml > 14:59:15,660 INFO [ServerInfo] OS-System: Mac OS X 10.4.6,ppc > 14:59:17,561 INFO [Server] Core system initialized > Failed to boot JBoss: > org.jboss.deployment.DeploymentException: url file:/Users/stefan/Development/JBoss/JBoss-4.0.4-EJB3/server/default/conf/jboss-service.xml could not be opened, does it exist? > at org.jboss.deployment.DeploymentInfo.<init>(DeploymentInfo.java:211) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:770) > at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755) > 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:585) > at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) > at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) > at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) > at $Proxy5.deploy(Unknown Source) > at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482) > at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362) > at org.jboss.Main.boot(Main.java:200) > at org.jboss.Main$1.run(Main.java:464) > at java.lang.Thread.run(Thread.java:613) > 14:59:19,416 INFO [Server] Runtime shutdown hook called, forceHalt: true > 14:59:19,419 INFO [Server] JBoss SHUTDOWN: Undeploying all packages > 14:59:19,472 INFO [Server] Shutdown complete -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-315) Break locks for state transfer

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-315?page=all ] Manik Surtani updated JBCACHE-315: ---------------------------------- Fix Version/s: (was: 1.4.1.GA) > Break locks for state transfer > ------------------------------ > > Key: JBCACHE-315 > URL: http://jira.jboss.com/jira/browse/JBCACHE-315 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assigned To: Vladimir Blagojevic > Priority: Critical > Fix For: 2.0.0.GA > > > State transfer needs to acquire a lock on the root to make sure all existing TXs have been completed. However, when a TX takes more time than the lock acquisition timeout, state transfer will fail. > Therefore, we need to forcefully acquire the locks for the state transfer by force-releasing the existing locks, and rolling back all TXs that held those locks. > This will ensure that state transfer always succeeds, at the expense of some rolled back TXs. > We need to investigate how this works with optimistic locking -- 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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-170) The INSTALL instructions remove the wrong XARecoveryModule

by Kevin Conner (JIRA)

The INSTALL instructions remove the wrong XARecoveryModule ---------------------------------------------------------- Key: JBTM-170 URL: http://jira.jboss.com/jira/browse/JBTM-170 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Reporter: Kevin Conner Assigned To: Kevin Conner The JTS INSTALL instructions includes a task to remove a XARecoveryModule from the jbossjts-properties.xml file. Unfortunately these instructions are reversed. The default config should remove the jts recovery module and the all config should remove the arjunacore recovery module. -- 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

17 years, 9 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2006