September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-589) Fix raw_socket performance tests.

by Ron Sigal (JIRA)

Fix raw_socket performance tests. --------------------------------- Key: JBREM-589 URL: http://jira.jboss.com/jira/browse/JBREM-589 Project: JBoss Remoting Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA (Boon) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.0.0.GA (Boon) raw_socket performance tests throwing NullPointerException in SocketPerformanceClient.makeInvocation(). -- 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, 4 months

1
2
0 / 0

[JBoss JIRA] Closed: (JBRULES-118) Map generated .java compilation errors to drl

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-118?page=all ] Mark Proctor closed JBRULES-118. -------------------------------- Resolution: Done > Map generated .java compilation errors to drl > ----------------------------------------------- > > Key: JBRULES-118 > URL: http://jira.jboss.com/jira/browse/JBRULES-118 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Drl Parser/Builder > Reporter: Mark Proctor > Assigned To: Mark Proctor > Fix For: 3.1-m3 > > > We know the method name for each descr. If we move the params all onto a single line we can use indexof to fine the start of each descr' compiled code. We can then use that to find the offiset and map the error to the descr. > This is complex as the error handling needs to be reworked. CompilationProblem objects should NOT be stuffed inside rule errors, but be seperate rule errors (hence can have multiple line errors). -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBRULES-118) Map generated .java compilation errors to drl

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-118?page=all ] Mark Proctor updated JBRULES-118: --------------------------------- Assignee: Mark Proctor (was: Bob McWhirter) > Map generated .java compilation errors to drl > ----------------------------------------------- > > Key: JBRULES-118 > URL: http://jira.jboss.com/jira/browse/JBRULES-118 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Drl Parser/Builder > Reporter: Mark Proctor > Assigned To: Mark Proctor > Fix For: 3.1-m3 > > > We know the method name for each descr. If we move the params all onto a single line we can use indexof to fine the start of each descr' compiled code. We can then use that to find the offiset and map the error to the descr. > This is complex as the error handling needs to be reworked. CompilationProblem objects should NOT be stuffed inside rule errors, but be seperate rule errors (hence can have multiple line errors). -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBRULES-118) Map generated .java compilation errors to drl

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-118?page=comments#action_12342695 ] Mark Proctor commented on JBRULES-118: -------------------------------------- yup, but you just fixed that :) Yes its not a nice solution, as runtime errors will still report the wrong line numbers - unless we "clone" errors replacing with correct filename and line numbers - but this can just get messy with stack traces etc. You are right that the whole solution is not that nice, but I can't think of any nicer way with execution of compiled code. > Map generated .java compilation errors to drl > ----------------------------------------------- > > Key: JBRULES-118 > URL: http://jira.jboss.com/jira/browse/JBRULES-118 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Drl Parser/Builder > Reporter: Mark Proctor > Assigned To: Bob McWhirter > Fix For: 3.1-m3 > > > We know the method name for each descr. If we move the params all onto a single line we can use indexof to fine the start of each descr' compiled code. We can then use that to find the offiset and map the error to the descr. > This is complex as the error handling needs to be reworked. CompilationProblem objects should NOT be stuffed inside rule errors, but be seperate rule errors (hence can have multiple line errors). -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Commented: (JGRP-2) Memory based flow control

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-2?page=comments#action_12342685 ] Bela Ban commented on JGRP-2: ----------------------------- Memory monitoring could be done by (JDK 5 only) java.lang.management.MemoryMXBean, with notifications. > Memory based flow control > ------------------------- > > Key: JGRP-2 > URL: http://jira.jboss.com/jira/browse/JGRP-2 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 2.2.8 > Reporter: Bela Ban > Assigned To: Bela Ban > Fix For: 2.x > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > Memory and retransmission based flow control protocol. Should be much faster than the current FC > on a fast network, we can still run out of memory because received_msgs/delivered_msgs becomes very big. > Instead of basing FC on the speed of the network, we should also take the number of messages processed > (a.k.a delivered_msgs/received_msgs) into account, and only send credits when that number falls below a > certain threshold. First: look at the number of received/delivered msgs in the perf test ! > --> Look into memory-based FC: criteria for sending credits are > - available free memory > - outstanding retransmission requests (sender sends with each message number of messages sent, > receiver keeps track of how many messages received, if diff is > threshold --> pause) > - [optional] latency -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-677) EJB3 deployments should be bound with rebind instead of bind

by Roland R?z (JIRA)

EJB3 deployments should be bound with rebind instead of bind ------------------------------------------------------------ Key: EJBTHREE-677 URL: http://jira.jboss.com/jira/browse/EJBTHREE-677 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC8 - FD Reporter: Roland R?z Using bind instead of rebind may cause trouble when the JNDI implementation is persistent (e.g. in an ldap directory) because deploying a previously crashed application will fail. I know that the current situation can also be seen as a feature because the developer cannot deploy two different beans with the same jndi name but this has in my opinion a lesser priority. Further the ejb 2.x stack uses rebind too. The request http://jira.jboss.com/jira/browse/EJBTHREE-51 describtes to use Util.rebind() but in fisheye I saw Util.bind(). -- 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, 4 months

4
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-678) RemoteBinding annotation doesn't use the default client binding of the remoting

by Roland R?z (JIRA)

RemoteBinding annotation doesn't use the default client binding of the remoting ------------------------------------------------------------------------------- Key: EJBTHREE-678 URL: http://jira.jboss.com/jira/browse/EJBTHREE-678 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: EJB 3.0 RC8 - FD Reporter: Roland R?z The org.jboss.annotation.ejb.RemoteBinding annotation configures the jndi binding, interceptor stack, the client bind url and the RemoteProxyFactroy. When the jboss remoting service is not configured using the url socket://0.0.0.0:3873 (not listening on the default port or using ssl), the programmer has to specify the the url when he wants to bind the bean to a different jndi context. The deployment has to be deployed into different JBoss instances (pre-production, production,...) with different ports, the deployment has to be rebuilt (different jboss.xml) or even recompiled (with different annotation value). I propose that the default "socket://0.0.0.0:3873" means the default of the remoting configuration or even better set the default to "" in the annotation which would be interpreted as the default remoting configuration. The following fixes the issue using the first described approach: org.jboss.ejb3.stateless.ProxyDeployer public void initializeRemoteBindingMetadata() { remoteBindings = (RemoteBindings) advisor.resolveAnnotation(RemoteBindings.class); if (remoteBindings == null) ... } else { // defaultClientBinding is more accurate that the constant in RemoteBinding if ("socket://0.0.0.0:3873".equals(binding.clientBindUrl())) { binding = new RemoteBindingImpl(binding.jndiBinding(), binding.interceptorStack(), defaultClientBinding, binding.factory()); } RemoteBinding[] list = {binding}; remoteBindings = new RemoteBindingsImpl(list); advisor.getAnnotations().addClassAnnotation(RemoteBindings.class, remoteBindings); } } } -- 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, 4 months

5
5
0 / 0

[JBoss JIRA] Updated: (JBIDE-332) Create a new splash image for JBossIDE 2.0

by Marshall Culpepper (JIRA)

[ http://jira.jboss.com/jira/browse/JBIDE-332?page=all ] Marshall Culpepper updated JBIDE-332: ------------------------------------- Attachment: new_splash_left_aligned.jpg Hey James.. the new splash screen is looking great.. I got around to integrating it along with your updated progress bar/message placement and I had a few comments/suggestions: 1) The BMP you sent didn't have any shadowing effects around the border, so it kind of "disappears" into the background if you're looking at something that is white (for example a web page in a browser or similar). Would you mind re-creating the splash with some kind of fade-out or border affect similar to what you showed in your original proposal? 2) Apparently the "loading" message text in eclipse is left-aligned only, meaning it doesn't flush over to the right side of the progress bar like in the mockup you sent. Do you think it would ruin the flow of the new splash screen if we changed the JBoss logo over to the right side, and put the progress message on the left? I'm attaching a screenshot of what the current splash looks like w/ the left aligned text. > Create a new splash image for JBossIDE 2.0 > ------------------------------------------ > > Key: JBIDE-332 > URL: http://jira.jboss.com/jira/browse/JBIDE-332 > Project: JBoss IDE > Issue Type: Feature Request > Reporter: Marshall Culpepper > Assigned To: James Cobb > Attachments: JBossIDE-splash.xcf, new_splash_left_aligned.jpg > > > We need a new splash screen for JBossIDE 2.0... > Preferrably the size shouldn't be bigger than 455x295. I've attached the splash screen we were using for 1.5 and 1.6 (it's in Gimp/XCF format) -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1900) Clustered webapp shouldn't require ClusteredSingleSignOn

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1900?page=all ] Brian Stansberry updated JBAS-1900: ----------------------------------- Summary: Clustered webapp shouldn't require ClusteredSingleSignOn (was: Clustered webapp shouldn't require ClusteredSingleSignon?) Workaround Description: I haven't tested this, so buyer beware. The request notes that using ClusteredSSO is not an option due to different sets of users for different webapps. Set the "requireReauthentication" attribute in the ClusteredSingleSignOnValve to "true". Each request will then be reauthenticated by the security layer, which should prevent users from one set accessing resources meant for another set. Workaround: [Workaround Exists] Suggested workaround added. > Clustered webapp shouldn't require ClusteredSingleSignOn > -------------------------------------------------------- > > Key: JBAS-1900 > URL: http://jira.jboss.com/jira/browse/JBAS-1900 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Clustering, Security > Affects Versions: JBossAS-4.0.2 Final > Reporter: Stan Silvert > Assigned To: Brian Stansberry > Priority: Minor > Fix For: JBossAS-4.0.6.CR1 > > > A customer had three webapps. The set of users for each webapp is different. So, they don't want single signon behavior. They do want HttpSessionReplication to take care of the credentials so that the user doesn't need to sign on when redirected to another server. It was found that we needed to enable clustered single signon to get this to work. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1014) NavigationPortlet enhancements

by Roy Russo (JIRA)

NavigationPortlet enhancements ------------------------------ Key: JBPORTAL-1014 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1014 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.Alpha1 Reporter: Roy Russo Assigned To: Roy Russo 1. Add explicit ordering support 2. Add localization support 3. Investigate feasibility of adding submenu support for subpage listing. All configuration options should be made available in the portlet.xml and overriden as preferences in the instances.xml. -- 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, 4 months

1
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2006