November 2009 - jboss-dev-forums - Jboss List Archives

[JBoss AS Development] - No of Concurrent Users supported by JBoss Application Serve

by ur.amit＠gmail.com

Hi all, We are evaluating different JEE Application servers for one of our project. the main criteria for the same is NO OF CONCURRENT USERS SUPPORTED in a particular Application Server for a fairly complex application. Please reply ASAP with some details or facts as my client will not agree to the simple Statements. Thanks is Advance. Amit Making Life better thru Software View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267044#4267044 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267044

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by adrian＠jboss.org

NOTE: If you did decide to make the next MC release 3.0.x then that would exclude this feature getting backported into JBoss5 since it would be a major change in a stable branch there. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267043#4267043 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267043

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | MC-3.0.x would be the time when you can change the public api. | | | Not even for 2.2.x? Which is where I planned this. | (I have no intentions of providing this for 2.0.x). No. Major changes need an update to the major version number. See for example: http://java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/versioning2.htm... Of course, Java breaks its own rules. e.g. the changes to the java.sql interfaces between 1.5 and 1.6 - but then that's really between 5.x and 6.x in Sun's bizarre versioning of java. ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267042#4267042 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267042

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by alesj

"adrian(a)jboss.org" wrote : | MC-3.0.x would be the time when you can change the public api. | Not even for 2.2.x? Which is where I planned this. (I have no intentions of providing this for 2.0.x). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267040#4267040 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267040

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by adrian＠jboss.org

"alesj" wrote : | I don't get this "instance of"? | Wouldn't ControllerContext implement this ServiceTracking mixin? | No, you can't add new methods to a public interface in a stable branch. It breaks any code that implements the interface directly rather than using the Abstract helper class (users of AbstractControllerContext should get the new methods with default implementations like I described above). MC-3.0.x would be the time when you can change the public api. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267038#4267038 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267038

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by adrian＠jboss.org

"alesj" wrote : "adrian(a)jboss.org" wrote : | | e.g. The OSGi api is at the deployment level | | by passing in the Bundle to getService(Bundle). | | | Wouldn't this be DeploymentControllerContext? | But that's just an implementation detail. ;-) The actual answer is yes for normal bundles, because they always represent top level deployments. OSGi bundles can't have subdeployments. But its also not for the SystemBundle which doesn't have a DeploymentUnit, it should use the SYSTEM level. I can imagine other cases where you might not have a specific ControllerContext but you do know what your ServiceTracker is (or something else does and can "hide" the link through its own api). Or as I described above, you may want to do tracking at subdeployment level. The DeploymentControllerContext is no use there because it maps to the top level deployment. DeploymentControllerContext.getScope() -> APPLICATION scope DeploymentUnit.getTopLevel().getScope() -> APPLICATION scope (Sub)DeploymentUnit.getScope() -> DEPLOYMENT scope So you can see that using the implement detail actually can give you the wrong answer. Because you are writing to the wrong api. ;-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267036#4267036 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267036

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by alesj

"adrian(a)jboss.org" wrote : It should be done on the calls to (un)getTarget() | | | | // Mixin interface for service tracking | | public interface ServiceTracking | | { | | ... | | | | if (me instanceOf ServiceTracking) | | { | | ServiceTracker otherTracker = me.getServiceTracker(); | | if (otherTracker != null) | | otherTracker.incrementUsing(this); | | } | | } | | return result; | | } | | | | The instanceOf ServiceTracking is for backwards compatibilty in case | some old ControllerContext doesn't know about ServiceTracking. | I don't get this "instance of"? Wouldn't ControllerContext implement this ServiceTracking mixin? OK, I guess since you called it mixin, it should be just AbstractControllerContext that impls it. But this makes lookup code ugly ... checking every context in metadata if it's ServiceTracking interface. Oh well, some copy pasting won't kill me ... :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267033#4267033 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267033

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by alesj

"adrian(a)jboss.org" wrote : | e.g. The OSGi api is at the deployment level | by passing in the Bundle to getService(Bundle). | Wouldn't this be DeploymentControllerContext? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267030#4267030 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267030

16 years, 4 months

1
0
0 / 0

[JBoss OSGi Development] - Re: Service integration with MC

by adrian＠jboss.org

You should also have some | (un)getTarget(ServiceTracker me) | methods when the caller doesn't have a specific ControllerContext but it does know its ServiceTracker. e.g. The OSGi api is at the deployment level by passing in the Bundle to getService(Bundle). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267022#4267022 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267022

16 years, 4 months

1
0
0 / 0

[JBoss Portal Development] - Portlet Container 2.1.0 release date?

by chenwang

I've been asking question in this forum about gatein/jboss portlet container - here is another one: when will the 2.1.0 version of the portlet container to be released? Currently it stays on Beta01 since September and there isn't any date set in Jira for 2.1.0-GA. It would be great if anyone of the developers can shed some light on this, as we're actively evaluating building an internal portal project based on the portlet container. Thanks! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267019#4267019 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267019

16 years, 4 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-dev-forums November 2009