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

[Design the new POJO MicroContainer] - Re: JIRA picture of MC work for JBossAS5 beta3

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | I also don't understand why JBoss5 beta3 is linking tasks from | JBossMC 2RC1? | For some reason JBossMC 2.0beta2 was released as 2.0beta3? :-) | | The idea was that the MC and AS would remain at the same release levels, | i.e. we do a JBossMC 2.0 beta3 for JBoss5 beta3 Since this is unfixable now (the releases are gone) one thing we do need to do is move all the completed RC1 work into a beta4 release along with the critical work I mentioned above (or are otherwise marked critical) as outstanding tasks. The other none critical outstanding tasks in RC1 can be left there. They are just improvements to the implementation and more testing that we'd like to get done in the 2.0 release. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066282#4066282 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066282

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - JIRA picture of MC work for JBossAS5 beta3

by adrian＠jboss.org

This task: http://jira.jboss.com/jira/browse/JBAS-63 isn't giving the full picture to me. First, I don't think that finishing the JMX Decorator is really a requirement for the beta. It would be good to be able define your mbean using annotations and have mbeans/pojos show up in the JMX console even if they are on-demand (and not started). But these aren't blockers for the beta3 release. Even the link to the MetaDataRepository task is wrong, since the real blocking issue is not the testing (which is what is linked there) but some deployers work. i.e. allowing the deployers to take part in the definition of the scope of deployments and their components for JSR77 The issues that are blockers for me (although not necessarily all MC related) are: 1) Finishing integrating the new VFSClassLoader http://jira.jboss.com/jira/browse/JBMICROCONT-182 which is also related to this http://jira.jboss.com/jira/browse/JBMICROCONT-186 2) Defining a stable profile service api (link Scott?) 3) And the deployer scope I described above (which didn't have a JIRA issue - I obviously overlooked it when I created the deployer TODOs because there was no TODO in the code :-) http://jira.jboss.com/jira/browse/JBMICROCONT-196 I also don't understand why JBoss5 beta3 is linking tasks from JBossMC 2RC1? For some reason JBossMC 2.0beta2 was released as 2.0beta3? :-) The idea was that the MC and AS would remain at the same release levels, i.e. we do a JBossMC 2.0 beta3 for JBoss5 beta3 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066278#4066278 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066278

18 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService todos for deployer changes

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | One point I didn't state was that we might still actually want | the managable sar view for "power users" who want to see | what is really going on. | Ok, that makes sense. Maybe that is the annotation the jca deployer puts on its resulting ServiceDeployment (a read-only annotation). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066264#4066264 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066264

18 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService todos for deployer changes

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | Ok, as we discussed on the call there may not be any interaction in terms of the managed object view between the jca and service deployers, other than, the service deployer should not be assuming that the ServiceDeployment is a managable sar for which it should be creating a management view. | One point I didn't state was that we might still actually want the managable sar view for "power users" who want to see what is really going on. But that would require some notion of the managed object being "synthetic" (i.e. an implementation detail) so it doesn't appear in the normal management view. It would just be a "read only" view for debugging purposes, not something that the profile service would maintain. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066262#4066262 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066262

18 years, 8 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - How do we control the order of deployment?

by joab

We are using jboss-seam-2.0 for our application development and application code is generated. All the entities are accessing the same entity manager and thus same data source. But I have to access a different data source for populating some information in a drop down. So I have one session bean which has an entity manager configured to access that data source. | @Stateless | @Name("csagent") | @Scope(ScopeType.SESSION) | public class CSAgentHelper implements CSAgent { | | @PersistenceContext(unitName = "misEntityManager") | private EntityManager em; | private CSAgentProfile csagentProfile; | | public CSAgentProfile getCsagentProfile() { | if (csagentProfile == null) { | csagentProfile = new CSAgentProfile(); | csagentProfile.setEmpStatusList(loadEmpStatusList()); | } | return csagentProfile; | } | | private List<EmpStatus> loadEmpStatusList() { | List resultList = null; | List empStatusList = new ArrayList(); | Query query = em.createQuery( | "select empStatus from EmpStatus empStatus where empStatus.activeFlag = 'Y'"); | resultList = query.getResultList(); | if (resultList != null) { | SelectItem selItem = null; | EmpStatus empStatus = null; | for (int i = 0; i < resultList.size(); i++) { | empStatus = (EmpStatus) resultList.get(i); | selItem = new SelectItem(empStatus.getEmpStatusId(), empStatus.getEmpStatusName()); | empStatusList.add(selItem); | } | } | return empStatusList; | } | } | Entity manager for the entity beans is configured like.. | @Entity | @Table(name = "AWARD") | @PersistenceContext(unitName = "empmstEntityManager") | @SequenceGenerator(name="SEQ_STORE", sequenceName="AGENTS_SEQ") | public class Award implements java.io.Serializable { | ----------- | ----------- | } | There is no issue with the deployment of entities. But when the session bean is deployed, I get an error like.. --- MBeans waiting for other MBeans --- ObjectName: jboss.j2ee:ear=empmst.ear,jar=empmst.jar,name=CSAgentHelper,service=EJB3 State: NOTYETINSTALLED I Depend On: persistence.units:unitName=misEntityManager --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM --- ObjectName: persistence.units:unitName=misEntityManager State: NOTYETINSTALLED Depends On Me: jboss.j2ee:ear=empmst.ear,jar=empmst.jar,name=CSAgentHelper,service=EJB3 Looks like it is a problem with the deployment order. When the session bean is deployed, it looks for entity manager which is not deployed yet. can anyone pls. help me fix this issue? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066258#4066258 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066258

18 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService todos for deployer changes

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | It does need a generic mechanism where the jca created managed object | is able to respond to a request (assuming it is runtime configurable) | "mydatasource".setProperty("max-pool-size", 100); | with a redirect to the MBean (or POJO). | | Only the JCA Deployer knows the ObjectName/Attribute | that "mydatasource"/max-pool-size maps to. | But that ObjectName should not be a part of what the client uses or even cares about. | | That's not to say it can't get help from the real ServiceDeployer to actually | handle the dispatch of the request. | It's only the real ServiceDeployer that knows how the ServiceMetaData | really maps to the runtime objects, i.e. mbeanserver.setAttribute(...); | | But that solution seems like a very long winded and brittle mechanism? | | My preferred solution would be to use KernelBus, but that is not | up-to-date in terms of dispatching MBean/POJO invocations | (Attribute and InvokeDispatchContext). Ok, as we discussed on the call there may not be any interaction in terms of the managed object view between the jca and service deployers, other than, the service deployer should not be assuming that the ServiceDeployment is a managable sar for which it should be creating a management view. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066257#4066257 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066257

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Property lookup interceptors

by alesj

"scott.stark(a)jboss.org" wrote : ..., but its not clear that supporting ldap namespace syntax is an mc concern. I agree. I'll just focus on the actual value-factory. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066249#4066249 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066249

18 years, 8 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Property lookup interceptors

by scott.stark＠jboss.org

This also relates to the metadata repository and loaders notion where the source of a property can start out coming from an xml file on a server, and then be overriden by a management layer to redirect to an ldap server/database. I can see plugging different sources of property values, but its not clear that supporting ldap namespace syntax is an mc concern. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066248#4066248 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066248

18 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService todos for deployer changes

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | There can be interaction between multiple ManagedDeploymentCreators. For example, with jca, the factories(the managed components) and properties are determined by the ManagedConnectionFactoryDeploymentGroup metadata, but there are runtime ops and stats that have to come from the ServiceMetaData of the mbeans that the jca layer currently uses as the runtime objects implementing the factories. Those mbeans should not be showing up as some manageable sar, while jms destinations currently are deployed as just a collection of mbeans. | Ok, I mentioned this before, but without any conclusion in how this should work. It does need a generic mechanism where the jca created managed object is able to respond to a request (assuming it is runtime configurable) "mydatasource".setProperty("max-pool-size", 100); with a redirect to the MBean (or POJO). Only the JCA Deployer knows the ObjectName/Attribute that "mydatasource"/max-pool-size maps to. But that ObjectName should not be a part of what the client uses or even cares about. That's not to say it can't get help from the real ServiceDeployer to actually handle the dispatch of the request. It's only the real ServiceDeployer that knows how the ServiceMetaData really maps to the runtime objects, i.e. mbeanserver.setAttribute(...); But that solution seems like a very long winded and brittle mechanism? My preferred solution would be to use KernelBus, but that is not up-to-date in terms of dispatching MBean/POJO invocations (Attribute and InvokeDispatchContext). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066245#4066245 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066245

18 years, 8 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService todos for deployer changes

by scott.stark＠jboss.org

It is wrong as the top level DeploymentUnit managed element needs to be a ManagedDeployment, not a ManagedObject instance or set. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066242#4066242 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066242

18 years, 8 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 July 2007