September 2007 - jboss-dev-forums

[Design of EJB 3.0] - Re: Redesign extended persistence context

by wolfc

Consider the following scenario: BeanA + BeanB share XPC. BeanA gets passivated (+ BeanB + XPC in one serialized unit). Where do I save the state? BeanA.id and/or BeanB.id? BeanB gets called / activated. What do I load and put into stateful cache? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082089#4082089 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082089

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mc release prep

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : The basic mc 2.0.0.Beta4 is released and is now used by jboss5. | Why did you release 2.0.0.Beta4 without first a snapshot of the latest stuff in jboss-head? I asked you not to do this. Maybe I should have created a blocker JIRA issue for it? There are a number of issues I wanted to tidyup (like investigating all those error messages at undeployment from @JMX) before we did the Beta4 release. I couldn't do this before, because I wasn't sure of the aop status so I didn't want to update aop-mc-int. This will have to wait until RC1 now :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082061#4082061 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082061

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mc release prep

by julien＠jboss.com

Why the repository component of that release does not declare any imports ? http://repository.jboss.com/jboss/microcontainer/2.0.0.Beta4/component-in... It makes MC very difficult to be consumed by other projects. "scott.stark(a)jboss.org" wrote : The basic mc 2.0.0.Beta4 is released and is now used by jboss5. The aggregate assembly seems broken so I don't know if we are putting out a standalone release as well. | [/url] View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082058#4082058 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082058

17 years, 1 month

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOP asintegration WITHOUT the integration :-)

by adrian＠jboss.org

"kabir.khan(a)jboss.com" wrote : "adrian(a)jboss.org" wrote : "adrian(a)jboss.org" wrote : | | | My preferred solution to use the scopes. i.e. you can choose | | | to deploy aop config at the SERVER, SUBSYSTEM, APPLICATION level, etc. | | | but this requires doing a lot work fixing everything to make sure | | | it sets the correct thread local MetaData for AOP to know which Scope | | | applies at runtime. | | | | | | | This thead local is really just a generalization of ejbs/mbeans | | setting the correct context classloader and java:/comp/env | | | | In principle once this is done. The only work required by AOP | | would be for the deployer to create hierarchical ... | | | | Is this work in progress? Or please let me know how I can help make this happen. | It's not work in progress, at least not yet. I only added the deployments scope a week ago. I'd suggest you try it yourself with a mock test, e.g. write an aspect that pushes the metadata from the advisor onto the stack and test it using the aop proxy where you can pass in the metadata. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082057#4082057 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082057

17 years, 1 month

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOP asintegration WITHOUT the integration :-)

by adrian＠jboss.org

"kabir.khan(a)jboss.com" wrote : Since Module is in the deployers-impl package I assume I should not use that from my AspectDeployer? I don't see any other way to get hold of of the information from ClassLoaderPolicy? When I created the "Module" class, I only anticipated it was an implementation detail of the classloader dependencies so I didn't put it in the spi. Any use of it would be a "hack" until the proper scoped metadata solution is done. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082052#4082052 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082052

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mc release prep

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : "scott.stark(a)jboss.org" wrote : The aop 2.0.0.alpha6 and mc 2.0.0.Beta4 release are ready, but there is a temp AspectDeployer that is broken. I assume this is due to the class loading being in flux. I have commented out the JBossScopedClassLoaderHelper usage. | | | | The latest version of AOP contains an updated AspectDeployer in the | asintegration project. The temp version in "system" is then redundant and should | be deleted with the configuration changed in the bootstrap-beans.xml, etc. | I am verifying this at the moment, stay tuned View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082051#4082051 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082051

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mc release prep

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : The aop 2.0.0.alpha6 and mc 2.0.0.Beta4 release are ready, but there is a temp AspectDeployer that is broken. I assume this is due to the class loading being in flux. I have commented out the JBossScopedClassLoaderHelper usage. | The latest version of AOP contains an updated AspectDeployer in the asintegration project. The temp version in "system" is then redundant and should be deleted with the configuration changed in the bootstrap-beans.xml, etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082048#4082048 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082048

17 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: mc release prep

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : So there is a circular dependencies between mc and aop at least in terms of how the mc is now setup as an assembly type of project. If I try to release jboss-container, it depends on the parent jboss-microcontainer from build/pom.xml and does not have a container/{trunk,tags} structure for an individual release. | | aop depends on jboss-container. I can manually release jboss-container, but how should these projects bet setup so that the mvn release process works for such interdependent projects? | Like I said before. The container project (and the classloader project) shouldn't be in the MC build. They are only there because the MC was initially the major consumer while we developed them. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082044#4082044 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082044

17 years, 1 month

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deployer order solely based on inputs/outputs now?

by adrian＠jboss.org

"bill.burke(a)jboss.com" wrote : Ok, after talking to Ales I think i get it. | | There would be: | | EJBParserDeployer | EJBDescribeDeployer | EJBComponentDeployer | | So, if my EJBDescribeDeployer is part of the DESCRIBE stage, it should happen after EVERY DeploymentUnit has gone through Parsing, right? This can only work if you add the dependencies to the deployment rather than the ejb instance. The same way OSGi dependencies work. It has to be real dependencies, no "flow" or ordering of deployers is going to solve the problem where deployments are deployed piecemeal, i.e. not at the same time, or even worse (more complicated) * redeployed * one of the transient dependencies is missing and deployed later The real solution is to create your own DependencyItem implementation like I've been telling you to over a year now. The JNDI plugin to the MC registry is stupidly inefficient, it's ok as an early hack to try out the idea. A DependencyItem that does the same thing, but only for those you expect to be JNDI dependencies is much more efficient. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082040#4082040 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082040

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Failure on XAResourceRecoveryTest

by mark.little＠jboss.com

Hi Clebert. I'll try to take a stab at this, but I think I need more information from you. "clebert.suconic(a)jboss.com" wrote : I need some help understanding this... | | XAResourceRecoveryTest::testRecoveryOnSend will aways fail if running after XARecoveryTest::testMockCoordinatorRecoveryWithJBossTSXids. | Fails in what way? Can you c&p the precise error message you get? anonymous wrote : | After some investigation, XAResourceRecoveryTest would fail by simply initializing TxControl by calling any method (such as TxControl.isEnabled()). | That should be OK. This class is just a wrapper/helper for things that are idempotent. anonymous wrote : | http://anonsvn.jboss.org/repos/messaging/trunk/tests/src/org/jboss/test/m... | | This is because testMockCoordinatorRecoveryWithJBossTSXids is instantiating com.arjuna.ats.jta.xa.XidImple, and that is initializing TxControl which is starting a ObjectStore. | No, it doesn't start an objectstore (an objectstore can never be started). It assigns one to the instance variable if one has not already been created, but that's it and it should be idempotent, i.e., subsequent tests would just do the same thing if they had to start from scratch. anonymous wrote : | Later on testRecoveryOnSend, the test would get a message "Told not to rollback {0}" on logs. I still don't know what's the reason but any help is welcome. | This message is coming from recovery and is because the recovery module has found some Xids that it doesn't know about and rather than roll it back (which would be bad if the machine/objectstore is being shared between other TM instances) it puts out this warning and ignores it. Check the TS failure docs on NodeName. If you can't find it, ping me on IM. anonymous wrote : | I was considering to comment the Mock Test out until we find a way to use the XidImple directly. | Hopefully that won't be necessary. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082030#4082030 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082030

17 years, 1 month

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 September 2007