November 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBRULES-244) Auto un-boxing/boxing

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-244?page=all ] Mark Proctor closed JBRULES-244. -------------------------------- Resolution: Won't Fix We aren't fixing this. With 3.1 now working with both primitives and objects the jdk1.5 autoboxing works fine. > Auto un-boxing/boxing > --------------------- > > Key: JBRULES-244 > URL: http://jira.jboss.com/jira/browse/JBRULES-244 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Rule Assemply/SPI > Reporter: Michael Neale > Assigned To: Mark Proctor > Fix For: 3.1-m1 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > When we bind to fields, we autobox. > It would be nice if we could remember what the original primitive was, and then unbox it when passing it into code bocks. > Also, for retvals, we should box up the result, so it JUST WORKS etc... > Mark, please embellish where in the code this stuff should go, as you know it best. One of us can then tackle 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

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAOP-301) FieldAccess for inherited fields does not get replaced

by Kabir Khan (JIRA)

FieldAccess for inherited fields does not get replaced ------------------------------------------------------ Key: JBAOP-301 URL: http://jira.jboss.com/jira/browse/JBAOP-301 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.alpha2 field(* POJO->field) field(* Sub->subField) class POJO { int field; } class Sub extends POJO { int subField; } Sub sub = new Sub(); sub.subField();//works as expected sub.field()//Does not get intercepted. The problem seems to be that CtClass.getRefClasses() now only returns classes that are explicitly referenced. -- 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

19 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (HIBERNATE-48) Add JBoss EULA

by Rajesh Rajasekaran (JIRA)

Add JBoss EULA -------------- Key: HIBERNATE-48 URL: http://jira.jboss.com/jira/browse/HIBERNATE-48 Project: Hibernate Issue Type: Feature Request Reporter: Rajesh Rajasekaran Assigned To: Steve Ebersole Attachments: JBossORG-EULA.txt Attached is the JBossORG-EULA.txt 1. The eula should be checked into the project's source tree. 2. The project's build should include the EULA in project distributables, ie, whatever is the unit of publish: zip, tgz, etc. -- 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

19 years, 6 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBREM-302) remote dynamic marshall loading not working on linux

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-302?page=all ] Tom Elrod updated JBREM-302: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > remote dynamic marshall loading not working on linux > ---------------------------------------------------- > > Key: JBREM-302 > URL: http://jira.jboss.com/jira/browse/JBREM-302 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: marshall > Affects Versions: 1.4.0 beta > Environment: Linux, JDK 1.4 > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Minor > Fix For: 2.2.0.Beta1 (Bluto) > > Attachments: SocketMarshallerLoadingTestCase-out.txt > > > The following test cases fail on Linux (and not on Windows): > org.jboss.test.remoting.marshall.dynamic.remote.http.HTTPMarshallerLoadingTestCase > org.jboss.test.remoting.marshall.dynamic.remote.socket.SocketMarshallerLoadingTestCase > Test output for SocketMarshallerLoadingTestCase attached, but says that server can not find the class: > org.jboss.test.remoting.marshall.dynamic.remote.socket.TestObject > However, confirmed that this class is within the jboss-remoting-loading-tests.jar, which is being set on the classpath (as shown in the output log). -- 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

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-129) remove oswego-concurrent lib

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-129?page=all ] Tom Elrod updated JBREM-129: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > remove oswego-concurrent lib > ---------------------------- > > Key: JBREM-129 > URL: http://jira.jboss.com/jira/browse/JBREM-129 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.2.0 final > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Optional > Fix For: 2.2.0.Beta1 (Bluto) > > > The oswego-concurrent jar is only being used by test code. If change this code to not use concurrent then can remove jar from remoting project (and distribution). -- 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

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-221) remove physical inclusion of docbook support directories

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-221?page=all ] Tom Elrod updated JBREM-221: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > remove physical inclusion of docbook support directories > -------------------------------------------------------- > > Key: JBREM-221 > URL: http://jira.jboss.com/jira/browse/JBREM-221 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.4.0 beta > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Optional > Fix For: 2.2.0.Beta1 (Bluto) > > > Included style and support directory under root docs directory. These are large in size and should either require checkoout of docbook-support project (as suggested on wiki) and point to that or find another solution that does not require getting these upon standard JBossRemoting checkout. -- 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

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-318) add remoting based chat sample

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-318?page=all ] Tom Elrod updated JBREM-318: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > add remoting based chat sample > ------------------------------ > > Key: JBREM-318 > URL: http://jira.jboss.com/jira/browse/JBREM-318 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 1.4.0 final > Reporter: Tom Elrod > Assigned To: Ron Sigal > Priority: Optional > Fix For: 2.2.0.Beta1 (Bluto) > > > Add a simple chat application using remoting for the communication layer to the remoting samples. -- 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

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-154) pluggable server resolver in client

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-154?page=all ] Tom Elrod updated JBREM-154: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > pluggable server resolver in client > ----------------------------------- > > Key: JBREM-154 > URL: http://jira.jboss.com/jira/browse/JBREM-154 > Project: JBoss Remoting > Issue Type: Feature Request > Components: general > Affects Versions: 1.2.0 final > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Minor > Fix For: 2.2.0.Beta1 (Bluto) > > > Per forum thread http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883462#3883462, need ability for the remoting client to have a pluggable way to resolve a server endpoint. -- 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

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-139) need automated test for servlet server invoker

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-139?page=all ] Tom Elrod updated JBREM-139: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > need automated test for servlet server invoker > ---------------------------------------------- > > Key: JBREM-139 > URL: http://jira.jboss.com/jira/browse/JBREM-139 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.2.0 final > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Minor > Fix For: 2.2.0.Beta1 (Bluto) > > > Tests for servlet invoker is manual since have to deploy servlet-invoker.war to jboss in order for it to work. Need to figure out if there > is an easy automated way to do this (since would currently require JBossAS, don't think realistic to run as unit test for JBossRemoting > test run). -- 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

19 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-373) clean up lease handling on server side

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-373?page=all ] Tom Elrod updated JBREM-373: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > clean up lease handling on server side > -------------------------------------- > > Key: JBREM-373 > URL: http://jira.jboss.com/jira/browse/JBREM-373 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 2.0.0.Beta1 > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Minor > Fix For: 2.2.0.Beta1 (Bluto) > > > In issue JBREM-372, put in a hack for cleaning up lease map within the ServerInvoker where would pass the clientLeases variable from ServerInvoker to the constructor of Lease. Then when LeaseTimerTask fired and event that client was dead, would remove itself from the ServerInvoker's lease map (by client id). > Should not have to pass in the lease map from ServerInvoker. Maybe better approach would be to have ServerInvoker add itself as listener, so when the connection failure event fired, it would be notified and remove the lease from the clientLeases map itself. -- 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

19 years, 6 months

1
0
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 2006