July 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBREM-27) Support for HTTP/HTTPS proxy

by susanin (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-27?page=comments#action_12340029 ] susanin commented on JBREM-27: ------------------------------ One additional note: You seem to use the originalURI in the transport() method of HTTPClientInvoker class: String targetURL = getLocator().getOriginalURI(); But i think that getLocator().getURI() is more correct. For example, when using annotations we sometimes use the following: @RemoteBinding(clientBindUrl="http://0.0.0.0:8888/SharedStateManager",jndiBinding="SharedStateManagerhttp") 0.0.0.0 is substituted by the real IP-number of the server during the deployment. Therefore, the originalURI of the locatoris http://0.0.0.0:8888/SharedStateManager, but URI field is correct and set to: http://x.y.z.w:8888/SharedStateManager where x.y.z.w is the IP of the server. With your current code, there is no easy way for a client to get the correct locator, since http://0.0.0.0:8888/SharedStateManager is returned. But may be it is also the same bug somewhere else, which makes use of originalURI, instead of URI. The fix is obvious and we hope to see it soon in the main branch. Best regards, Ivan > Support for HTTP/HTTPS proxy > ---------------------------- > > Key: JBREM-27 > URL: http://jira.jboss.com/jira/browse/JBREM-27 > Project: JBoss Remoting > Issue Type: Feature Request > Components: transport > Reporter: Thomas Diesler > Assigned To: Tom Elrod > Priority: Optional > Fix For: 1.2.0 final > > > This request showed up on the web services forum. Proxies are currently suported in axis-ws4ee.jar -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3318) Secondary http sessions in a cross-context request are not replicated

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3318?page=all ] Brian Stansberry updated JBAS-3318: ----------------------------------- Fix Version/s: JBossAS-4.0.5.CR1 (was: JBossAS-5.0.0.Beta) (was: JBossAS-4.0.6.CR1) I want to try to get this done for 4.0.5 as the Portal guys want it. > Secondary http sessions in a cross-context request are not replicated > --------------------------------------------------------------------- > > Key: JBAS-3318 > URL: http://jira.jboss.com/jira/browse/JBAS-3318 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service, Clustering > Affects Versions: JBossAS-3.2.7 Final, JBossAS-3.2.6 Final, JBossAS-4.0.2 Final, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1, JBossAS-3.2.8 Final, JBossAS-3.2.8.SP1, JBossAS-4.0.4.GA > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Fix For: JBossAS-4.0.5.CR1 > > Original Estimate: 4 days > Remaining Estimate: 4 days > > If cross-context requests are enabled and a servlet accesses the request dispatcher and dispatches the request to a different context, no session replication is performed for the session in that second context. This is because a dispatched request bypasses the ClusteredSessionValve, and thus replication is not triggered. > Likely solution is to have ClusteredSessionValve create some sort of ThreadLocal replication context. Any JBossCacheManager that accesses a session will associate itself and the session with the replication context.. Then when the request returns through the ClusteredSessionValve, all sessions in the context will be replicated. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBAS-2695) LRUStatefulContextCachePolicy implementation of maxBeanLife removal is flawed

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2695?page=all ] Ben Wang resolved JBAS-2695. ---------------------------- Fix Version/s: (was: JBossAS-4.0.5.CR1) Resolution: Won't Fix After some more thought, I really think this is not a critical issue anymore since it is really a corner case and there is a workaround for ejb2. For ejb3, this won't apply. So I am going to mark it as "Won't Fix" unless someone objects. > LRUStatefulContextCachePolicy implementation of maxBeanLife removal is flawed > ----------------------------------------------------------------------------- > > Key: JBAS-2695 > URL: http://jira.jboss.com/jira/browse/JBAS-2695 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB2 > Affects Versions: JBossAS-3.2.8RC1, JBossAS-4.0.3 SP1 > Reporter: Scott M Stark > Assigned To: Ben Wang > Priority: Critical > > The RemoverTask of the org.jboss.ejb.plugins.LRUStatefulContextCachePolicy performs removal of passivated beans based on a maxBeanLife - maxBeanAge diff. This is invalid for beans passivated due to size. The calculation should be maxBeanLife - (the per bean instance time of inactivity). The reason is a bean may be passivated very quickly due to cache size constraints and if the maxBeanLife - maxBeanAge == 0, just a quickly thrown away. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3424) Create mechanism to inject additional_data into multiplexed JChannel

by Brian Stansberry (JIRA)

Create mechanism to inject additional_data into multiplexed JChannel -------------------------------------------------------------------- Key: JBAS-3424 URL: http://jira.jboss.com/jira/browse/JBAS-3424 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.CR1 ClusterPartition requires the Channel it uses to be configured with additional_data, which it uses to ensure a unique node id. Need to ensure this data is present if the channel was already created/connected via the multiplexer/JChannelFactory. This is a temporary requirement until JGRP-129 is completed. I'll implement this by subclassing JChannelFactory with an AS-specific version that creates and injects the additional_data before returning a channel. -- 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, 10 months

1
2
0 / 0

[JBoss JIRA] Resolved: (EJBTHREE-500) Use JBossCache passivation feature for clustered ejb3 SFSB

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-500?page=all ] Ben Wang resolved EJBTHREE-500. ------------------------------- Fix Version/s: EJB 3.0 RC9 - FD Resolution: Done I have ported the solution both to 4.0 and head. The JBoss Cache version needed is 1.4. Basically, the only change is that we are using the passivation feature in JBC now (ejb3-clustered-stateful-service.xml). User can still tune the eviction thread wakeUpIntervalSeconds and also the location of the FileCacheLoader. Additionally, if the bean is currently in use (and inactive for a while), we won't passivate/evict it untill it is no longer in use. The rest of the configuration should stay the same. > Use JBossCache passivation feature for clustered ejb3 SFSB > ---------------------------------------------------------- > > Key: EJBTHREE-500 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-500 > Project: EJB 3.0 > Issue Type: Task > Components: Clustering > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: EJB 3.0 RC9 - FD > > Original Estimate: 1 week, 1 day > Time Spent: 1 week > Remaining Estimate: 1 day > > Currently the clustered sfsb uses its own passivation implmentation because JBossCache didn't offer that previously. However, now that it has this feature, we should refactor to use that. There is a corresonding Forum post for this discussion. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Resolved: (EJBTHREE-580) Test out failover passivation under JBC

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-580?page=all ] Ben Wang resolved EJBTHREE-580. ------------------------------- Resolution: Done > Test out failover passivation under JBC > --------------------------------------- > > Key: EJBTHREE-580 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-580 > Project: EJB 3.0 > Issue Type: Sub-task > Components: Clustering > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: EJB 3.0 RC9 - FD > > > In PassivationUnitTestCase, we need to add a test case that test the passivation with failover case. And if it fails, fix it accordingly. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3318) Secondary http sessions in a cross-context request are not replicated

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3318?page=all ] Dimitris Andreadis updated JBAS-3318: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) Brian, moving to the next release, unless you want to work on it. > Secondary http sessions in a cross-context request are not replicated > --------------------------------------------------------------------- > > Key: JBAS-3318 > URL: http://jira.jboss.com/jira/browse/JBAS-3318 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service, Clustering > Affects Versions: JBossAS-3.2.7 Final, JBossAS-3.2.6 Final, JBossAS-4.0.2 Final, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1, JBossAS-3.2.8 Final, JBossAS-3.2.8.SP1, JBossAS-4.0.4.GA > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1 > > Original Estimate: 4 days > Remaining Estimate: 4 days > > If cross-context requests are enabled and a servlet accesses the request dispatcher and dispatches the request to a different context, no session replication is performed for the session in that second context. This is because a dispatched request bypasses the ClusteredSessionValve, and thus replication is not triggered. > Likely solution is to have ClusteredSessionValve create some sort of ThreadLocal replication context. Any JBossCacheManager that accesses a session will associate itself and the session with the replication context.. Then when the request returns through the ClusteredSessionValve, all sessions in the context will be replicated. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-969) 401 status when trying to use ManagementPortlet

by Boleslaw Dawidowicz (JIRA)

401 status when trying to use ManagementPortlet ----------------------------------------------- Key: JBPORTAL-969 URL: http://jira.jboss.com/jira/browse/JBPORTAL-969 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4 Final Reporter: Boleslaw Dawidowicz Assigned To: Boleslaw Dawidowicz Priority: Optional 401 status when trying to use ManagementPortlet -- 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, 10 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBAS-3353) Add support for jmx-depends to mc bean deployer

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3353?page=all ] Dimitris Andreadis updated JBAS-3353: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Add support for jmx-depends to mc bean deployer > ----------------------------------------------- > > Key: JBAS-3353 > URL: http://jira.jboss.com/jira/browse/JBAS-3353 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JMX, MicroContainer bus > Affects Versions: JBossAS-4.0.4.GA > Reporter: Scott M Stark > Assigned To: Scott M Stark > Fix For: JBossAS-4.0.6.CR1 > > > There is a mismatch in terms of dependencies between the mc beans and the legacy jmx beans that affect integration of the bean deployer in jboss-4.0.x. It should be possible to extend the org.jboss.kernel.plugins.deployment.xml.BeanSchemaBinding to add a jmx-depends tag that specifies the jmx mbeans that the org.jboss.kernel.deployment.jboss.JBossBeanDeployment which is registered with the jmx kernel depends on. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-2904) Allow for ear modules to be deployed in the order that they are declared in application.xml

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2904?page=comments#action_12340019 ] Dimitris Andreadis commented on JBAS-2904: ------------------------------------------ Vicky, have you progressed with this? > Allow for ear modules to be deployed in the order that they are declared in application.xml > ------------------------------------------------------------------------------------------- > > Key: JBAS-2904 > URL: http://jira.jboss.com/jira/browse/JBAS-2904 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Deployment services > Affects Versions: JBossAS-4.0.3 SP1, JBossAS-3.2.8.SP1 > Reporter: Jim Moran > Assigned To: Vicky Kak > Fix For: JBossAS-3.2.8.SP2, JBossAS-4.0.5.CR1 > > -- 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, 10 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 July 2006