January 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Class dependencies

by adrian＠jboss.org

No because "On Demand" doesn't "On Undemand". :-) If somebody references the bean we deploy it, but we don't undeploy it when it is de-referenced. That is mainly because it would wasted effort if the referencer is just redeloying. For class dependencies the issue is different. You have to redeploy if the class changes or undeploy if the class is removed. It's not difficult, the semantics are just a bit exacting. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008956#4008956 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008956

17 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Scoped beans deployment

by adrian＠jboss.org

"bill.burke(a)jboss.com" wrote : Adrian, I'm not grokking here... See the scoped metadata in org.jboss.metadata in the container project and its integration with the MC which was discussed/done within the last couple of months. anonymous wrote : | | | | | <bean name="bar/> | | </scope | | That won't work because you define the scopes hierarchically but also somewhat randomly (even without introducing session/thread/transaction/converstation/etc. :-) e.g. You can have a bean scope myapplication/mydeployment1/mybean1 myapplication/mydeployment1/mybean2 myapplication/mydeployment2/mybean1 But you also want to be able to define it in code, e.g. adding beans to a subsystem scope which isn't part of a deployment but deployments can be in that subsystem. e.g. I know this part of the jca code goes in the jboss-jca subsystem scope | @org.jboss.metadata.scope.Subsystem("jboss-jca") | public class MyJCAImplementationObject {} | So it needs to be abitrary scope annotations against the bean (and the deployment for convenience). anonymous wrote : | Kernel app= kernel.createScope("Application"); | Kernel session = app.createScope("session"); | Yes, you need to be able to create a child kernel see my point (1) in the first response, but you also need to add it to the MetaData scope otherwise how does somebody which kernel to use in an abitrary context. That is the purpose of the MetaData/MetaDataStack. NOTE: This is all very speculative since besides maintaining the MetaDataRepository yourself in some code none of this exists. i.e. there is nothing that says I want to deploy this metadata into this scope. That is what I meant before when I said: "Although I think a more general notion would come out of the work we need to do to define scoped metadata". The repository exists with all the plumbing, but there is nothing to fill it! :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008952#4008952 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008952

17 years, 11 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: SOAP request missing namespace

by heiko.braun＠jboss.com

Please post these questions to the user forum: http://www.jboss.org/index.html?module=bb&op=viewforum&f=200 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008944#4008944 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008944

17 years, 11 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Issues with passivation of nested SFSBs

by bstansberry＠jboss.com

"bill.burke(a)jboss.com" wrote : | At first, the parent SFSB owns all the children. If a child is "touched" by an invocation, it must ping the parent to replicate the whole tree: parent and all its children. Easily encapsulated in the StatefulReplicationInterceptor. anonymous wrote : If the parent is removed, a child is picked as the new "parent". This will be lot of work, for I'm not sure what gain vs. leaving the old parent context in the cache, but marked "removed" and with refs to any unneeded state nulled out. You've got to: 1) Pick a child (ok, trivial) 2) Move the data to the child (not sure if there are any integration issues) 3) Add all of the parent's children to the new "semi-parent". 4) Notify all the children of the new semi-parent 5) Do a lookup of the ProxiedStatefulBeanContext of each of the children (no direct ref to it) and modify it to point to the new parent. 6) Replace the cached context for the new "semi-parent" so it's no longer a ProxiedStatefulBeanContext, but rather a regular one (otherwise any calls to the new parent will fail). 7) Replicate every affected context so the rest of the cluster knows what you did. Probably should do this in a tx. anonymous wrote : As for your concurrency problem. I don't think we should code for this and document that that scenario is not supported. SFSBs are supposed to be used by one client, not multiple clients concurrently. This will make things easier IMO. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008942#4008942 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008942

17 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Precedence level

by bill.burke＠jboss.com

anonymous wrote : | e.g. suppose we define a jboss-jca group so you can depend upon | all of jca being deployed, but then you add a new rar to the jboss-jca group? I see your point. The aliased dependent components would not be allowed to start until a complete scan was complete. So, you couldn't resolve dependencies until every single deployment in the system had been at least described. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008939#4008939 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008939

17 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Class dependencies

by bill.burke＠jboss.com

don't you have the same issue with "On Demand" stuff? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008935#4008935 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008935

17 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Precedence level

by scott.stark＠jboss.org

A dependency + an order is just introduces an implicit dependency on the components in the dependency tree with a lower order. The problem is defining the dependency tree as Adrian points out. We would need some alternate dependency scope notion that could be restricted to the current top-level deployment, as an example. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008931#4008931 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008931

17 years, 11 months

1
0
0 / 0

[Javassist development Forum] - FYI: Fixed the annotation equals/hashCode

by adrian＠jboss.org

I found a bug in the annotation's equals/hashcode processing. It wasn't following the spec so you couldn't compare them with JDK annotations or use them in the same collections. I've fixed it in javassist head. Related: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008928#4008928 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008930#4008930 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008930

17 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Broken javassist tests

by adrian＠jboss.org

FYI. Some of the javassist annotation tests are broken. This is due to a bug in the way its annotation does equals/hashCode. I've fixed the problem in javassist, but it needs an updated version for these tests to start working again. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008928#4008928 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008928

17 years, 11 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Class dependencies

by adrian＠jboss.org

This has the same problem as the precedence. When do you check that the class is available? Under hotdeployment, the class could be added later and even removed and redeployed. When classloading dependencies are implemented (needs integration between the classloader and the kernel - see other discussions) a better feature might be to say: | <bean ... class="org.drools.Shit" optional="true"/> | So if the class doesn't exist we don't report it as a missing dependency. We just don't start the bean until somebody deploys the class. This would also extend to other dependencies, not just classes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4008927#4008927 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4008927

17 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2007