May 2008 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: expressing dependent states

by adrian＠jboss.org

"jhalliday" wrote : Hmm, presumably injecting it as a parameter to some lifecycle method ensures the property has actually been configured correctly (ORBService may setORB(...) in e.g. startService()), whereas injecting it as a property on the bean does not. Property injection is built on the assumption that a bean's properties are initialized at bean creation time I guess? Besides, if I inject it as a property of my bean, I may be tempted to use it in create() rather than start(), which would be against the guidelines I think. So the correct approach would seem to be | No. "inject" is different from "depends". The MC is a lot more flexible than the old service lifecycle. In fact, the JBoss5 service lifecycle is more flexible than the old JBoss4 one. ;-) depends is a two phase lifecycle create/start that is backwards compatible with the old MBean service lifecycle. The MBean lifecycle was originally done as two phase to solve circular dependency issues (which most services don't have anyway ;-). inject works by requiring the dependency is INSTALLED (i.e. it has completed its whole lifecycle) before the object can be injected into the dependee. Circular dependencies are handled in a different (more explicit) way in the MC, see the getting started docs. i.e. You can override what state the dependency must be in before it is injected. e.g. You can inject an MBean instance or property into a constructor, propertly, lifecycle method parameter, etc. and it will guarantee the MBean has been fully started before that part of the lifecycle gets invoked. There's a different philosophy between the two mechanisms. ASIDE: In JBoss5 MBeans have gained some (but not all) of this injection flexibility from the ServiceController being implemented on top of the MC. e.g. There is now a proper lifecycle for the setAttribute() invocations on the mbeans so they can use "inject" semantics rather than "depends optional-attribute". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152414#4152414 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152414

17 years, 10 months

1
0
0 / 0

[Javassist development Forum] - Re: Patch process for non committers?

by scott.stark＠jboss.org

Also please sign a contributor agreement: http://www.jboss.org/contributor/ View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152412#4152412 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152412

17 years, 10 months

1
0
0 / 0

[Javassist development Forum] - Re: Patch process for non committers?

by david.lloyd＠jboss.com

I'd open a JIRA ticket for each change at http://jira.jboss.com/jira/browse/JASSIST, and include the patch for each change as an attachment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152410#4152410 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152410

17 years, 10 months

1
0
0 / 0

[QA of JBoss Portal] - automating jboss portal admin ui testing usign selenium

by prabhat.jha＠jboss.com

Leonid, Here are things you should do first: 1. Get familiar with JBoss Portal Product. You can read http://docs.jboss.com/jbportal/v2.6.4/quickstartuser/html_single/. Your goal will be to get familiar with Portal's administration UI. 2. Get familiar with Selenium. 3. Look at the test case http://anonsvn.jboss.org/repos/portal/modules/test/trunk/remote/src/test/... The test is run from http://anonsvn.jboss.org/repos/portal/modules/test/trunk/remote/src/test/... If you can run that test then you will be in a position to write similar test case for JBoss Portal. regards, Prabhat View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152404#4152404 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152404

17 years, 10 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JCRMessageStoreImpl store only message body?

by maeste

"mark.little(a)jboss.com" wrote : The message store should be implementation agnostic. It certainly started out that way. JCR is good as a specific type of implementation, but that should not be forced through to the front-end service interface. Agree 100%. I thought to don't change interface, but only the current JCR implementation. Are you saying it would be impossible, and I have to take care also to review the front-end interface (keeping of course in mind it have to be implementation agnostic)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152403#4152403 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152403

17 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: expressing dependent states

by jhalliday

Hmm, presumably injecting it as a parameter to some lifecycle method ensures the property has actually been configured correctly (ORBService may setORB(...) in e.g. startService()), whereas injecting it as a property on the bean does not. Property injection is built on the assumption that a bean's properties are initialized at bean creation time I guess? Besides, if I inject it as a property of my bean, I may be tempted to use it in create() rather than start(), which would be against the guidelines I think. So the correct approach would seem to be | <start> | <parameter><inject bean="ORBService" property="ORB"/></parameter> | </start> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152398#4152398 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152398

17 years, 10 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBMETA-42

by scott.stark＠jboss.org

It stores the non-transient managed attachments. Any attachments derived from the managed metadata should be transient attachments that are not stored. Merged metadata should be transient. The deployer that adds the attachment controls this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152391#4152391 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152391

17 years, 10 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBMETA-42

by wolfc

But does it store the orginal JBossSessionBeanMetaData, the merged one, or the final one (in this case JBossSessionPolicyDecorator)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152386#4152386 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152386

17 years, 10 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JBMETA-42

by scott.stark＠jboss.org

"wolfc" wrote : Patch #2 is a continuation of the first were I reverted the baseJndiName in JBossEnterpriseBeanMetaData. Subsequently I made it obsolete by introducing a JBossSessionPolicyDecorator which associates a JBossSessionBeanMetaData with a working JNDI binding policy. | As can be seen in the jbmeta42 test this requires an extra step before the meta data is offered to the deployer, but it completely separates out the logic of JNDI name resolving while having it completely obscured to the deployer itself. | | Unit tests are passing 100%, but previously there was a possible issue with profile service storing the wrong data. Is that still the case in this setup? The profile service would only store the non-XmlTransient values, so as long determineResolvedJndiName does not set something like the jndiName, mappedName, its not interfering with the administered view. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152385#4152385 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152385

17 years, 10 months

1
0
0 / 0

[Javassist development Forum] - Patch process for non committers?

by PaulKeeble

I am finding a number of bugs and general enhancements that I need as I go about implementing my project on top of Javassist. At the moment I have a number of workarounds in my code base. My project however is open source so I can happily provide the fixes and enhancements for inclusion directly into Javassist. If I was to generate patch files on top of say the 3.6 GA code base where would I put them so that a code owner could pick them up and make comments and ultimately apply them for a future release? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152383#4152383 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152383

17 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-dev-forums May 2008