November 2006 - jboss-jira - Jboss List Archives

[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

18 years, 11 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

18 years, 11 months

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

18 years, 11 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

18 years, 11 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

18 years, 11 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

18 years, 11 months

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

18 years, 11 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

18 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-167) RMI Invoker does not use true remoting marshalling/unmarshalling

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-167?page=all ] Tom Elrod updated JBREM-167: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > RMI Invoker does not use true remoting marshalling/unmarshalling > ---------------------------------------------------------------- > > Key: JBREM-167 > URL: http://jira.jboss.com/jira/browse/JBREM-167 > Project: JBoss Remoting > Issue Type: Bug > Components: transport > Affects Versions: 1.2.0 final > Reporter: Tom Elrod > Assigned To: Tom Elrod > Priority: Minor > Fix For: 2.2.0.Beta1 (Bluto) > > > In process of fixing JBREM-165 (RMI support for UnifiedInvoker), have added ability to call on mashaller when making request so that can modify payload before sending. Although the RMIInvokerClient does use the configured marshaller, it does not use the configured unmarshaller (RMIInvokerServer is the opposite). This was done to get JBREM-165 working, but is not a total solution and needs to be fixed so anyone can add a marshaller/unmarshaller for RMI invoker that will be called both ways (in and out) on both the client and server. -- 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

18 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-510) SSLSocketBuilder should require a SocketFactory in server mode to have a keystore.

by Tom Elrod (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-510?page=all ] Tom Elrod updated JBREM-510: ----------------------------- Fix Version/s: 2.2.0.Beta1 (Bluto) (was: 2.2.0.Alpha3 (Bluto)) > SSLSocketBuilder should require a SocketFactory in server mode to have a keystore. > ---------------------------------------------------------------------------------- > > Key: JBREM-510 > URL: http://jira.jboss.com/jira/browse/JBREM-510 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.2.0.Alpha3 (Bluto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Priority: Minor > Fix For: 2.2.0.Beta1 (Bluto) > > > SSLSocketBuilder needs to > 1. allow a ServerSocketFactory in client mode to not have a keystore, and > 2. require a SocketFactory in server mode to have a keystore. > Part 1 is fixed as of 6/20/06, as part of changes made for JBREM-368/JBREM-491. -- 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

18 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2006