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

[Design the new POJO MicroContainer] - Re: Case sensitivity in injecting a bean's property

by scott.stark＠jboss.org

A task to create the interaction tests http://jira.jboss.com/jira/browse/JBAS-4009 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005475#4005475 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005475

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: serializable KernelDeployment

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : "alesj" wrote : | | Ok, for MetaData there is no problem. | | What do we do with JavaBeans (which now fail - since with wildcard test's we use plain java.lang.Object)? | | | | Just change the test to use something like the following class: | | | | package org.jboss.test.....; | | | | import java.io.Serializable; | | | | public class SerializableObject implements Serializable | | { | | private static final long serialVersionUID = -1L; | | } | | We do have the ability to serialize non-Serializable objects, and this notion should be coming in as an annotation/external metadata passed to the serialization layer rather than a tagging interface that has to be seen in the type system in my view. Exposing Serializable in the mc apis is too onerous a contract. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005471#4005471 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005471

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: DataSource/ServiceXSLDeployer processing issue

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : DEPLOYMENT PROTOCOL | | This is something that is not a part of the original prototype but it is a part of the | original design. | | The basic idea is that the deployers can be run in two modes. | 1) Runtime - this is what is implemented, it is the full deployment | 2) Profile Service - in this case, the "real deployers" create contexts that have | stubbed out actions for the MC and JMX layers. | | That is when it runs in Profile Service mode, it still goes through the full | deployment process, creates all the contexts and tries to resolve dependencies, | but it doesn't create any objects or invoke any setters or lifecycle methods. | | NOTE: This is only for the deployments. It does need to do the full work | for the deployers and classloaders otherwise they wouldn't be able to do anything. :-) Then the real deployers simply need to select the approriate contexts based on a DeploymentMode(Runtime,Validation) type of attachment. This of course precludes non-real deployers from directly interacting with any kernels. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005468#4005468 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005468

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: DataSource/ServiceXSLDeployer processing issue

by scott.stark＠jboss.org

"bill.burke(a)jboss.com" wrote : | The EJB Deployer can do what it already does: instantiate the container itself and install them manually into the kernel. No need for special MC states. Then your back to the old monolithic model of mixing describing how to do something with doing it. This will complicate interaction with generalized notions like admin ops affecting all transport interfaces, clustering behaviors, as well as resue of code across server versions. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005463#4005463 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005463

19 years, 2 months

1
0
0 / 0

[Design of JBoss Build System] - Creating a subversion trunks folder in JBoss Common

by pgier

I'm not sure if this is the right forum for this, but I would like to create a trunks folder at the root of the JBoss commons project. It would use svn externals properties to map to each of the subproject trunk folders. This would allow us to keep separate the trunk/tags/branches separate for the subfolders, but also allow an easy checkout process. Currently we have to check out each common subproject trunk folder separately. If I create a folder called "trunks" here: https://svn.jboss.org/repos/common/trunks I can put one svn property that maps to the trunk folder of each of the subprojects. So that all the subproject (common-core, common-logging-jdk, etc) trunk folders can be checked out at one time. For more information about how this works you can look here: http://svnbook.red-bean.com/en/1.1/ch07s04.html View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005462#4005462 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005462

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: DataSource/ServiceXSLDeployer processing issue

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : This seems to be getting very confused? | | ATTACHMENTS | | The original design was the following: | | You have two types of attachment: | 1) Transient - these are created by the parsing deployers from the raw xml | inside the deployments | 2) Predetermined - these are what the profile service (or some other invoker of the | deployers) passes in to override what is in the deployment. | | The Predetermined attachments are a sort of alt-dd but done programmatically. | | I can see an argument for having a third type of attachment which is internal state | related to the deployment but it is stuff that we don't want the profile service/management | layer to override. It will always be constructed at runtime. | | However, this can also be trivially dealt with by the ManagedObjectBuilder | NOT creating a ManagedObject for that attachment type. I don't see the confusion as, other than the new third form of attachment, this is how I have described the attachments usage is it not? The notion of the third attachment being classified separately was really only to control what attachments have some serialization requirement. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005460#4005460 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005460

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: DataSource/ServiceXSLDeployer processing issue

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : COMPONENTS | | This is very much a prototype. When I wrote this it was just to get something | working and express the idea. Like I said before, this needs revisiting and | doing properly. | | But what I will say is that components are an implementation detail. | The profile service should not be interested in the components directly, | it is not going to touch their attachments. | | The components that get constructed from a particular metadata model | can change from release to release. | | The only part the profile service needs to know about these is the | context names. i.e. what are the MBean/POJO names | so it can map missing dependencies back to the original deployment | that caused them. There is a notion of components in the profile service since the management interface wants to be able to query by functional detail rather than structural. A service deployment has mbeans which have managed objects. How this maps back onto the DeploymentUnit attachments depends on the ModelObjectBuilder. I don't see why it could not map to a component DeploymentUnit if desired. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005458#4005458 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005458

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - ManagementView refresh

by scott.stark＠jboss.org

As a status, I am reving the profile service ManagementView to better align with the jsr88 notions, expose the deployment structure, and support the component type notion Charles wanted. The two main query by type methods of the ManagementView become: | /** | * Get the deployments of a type. | * @param type - the deployment or module type. | * @return the possibly empty set of deployment with the given type. | * @throws Exception | */ | public Set<ManagedDeployment> getDeploymentsForType(String type) | throws Exception; | | /** | * Get the components of a type. The | * @param type - the component type. | * @return the possibly empty set of components with the given type. | * @throws Exception | */ | public Set<ManagedComponent> getComponentsForType(ComponentType type) | throws Exception; | The associated ManagedDeployment, ManagedComponent and ComponentType are: | /** | * A collection of ManagedComponent and structural information | * about a deployment. | * | * @author Scott.Stark(a)jboss.org | * @version $Revision:$ | */ | public interface ManagedDeployment | { | public String getName(); | public DeploymentPhase getDeploymentPhase(); | /** | * Get the deployment/module types. | * @return deployment types | */ | public Set<String> getType(); | public ManagedObject getManagedObject(); | /** | * Get the ManagedComponents for the deployment module. | * @return ManagedComponents for the deployment module. | */ | public List<ManagedComponent> getComponents(); | /** | * Get the nested deployment modules. | * @return nested deployment modules. | */ | public List<ManagedDeployment> getChildren(); | | /** | * Get the DeploymentTemplate names for components | * that can be added to this deployment. | * @return | */ | public Set<String> getComponentTemplateNames(); | public DeploymentTemplateInfo getTemplate(String name); | /** | * Add a component to this deployment | * @param info | * @return | */ | public ManagedComponent addComponent(DeploymentTemplateInfo info); | public void removeComponent(ManagedComponent mc); | | /** | * Get the DeploymentTemplate names for deployments | * that can be added to this deployment. | * @return | */ | public Set<String> getDeploymentTemplateNames(); | /** | * Add a deployment | * @param info | * @return | */ | public ManagedDeployment addModule(DeploymentTemplateInfo info); | } | | /** | * A runtime component associated with a deployment. | * | * @author Scott.Stark(a)jboss.org | * @version $Revision:$ | */ | public interface ManagedComponent | { | /** | * The component name, typically only unique within the ManagedDeployment | * @return omponent name | */ | public String getName(); | /** | * The component classification as a type/subtype. | * @return component type. | */ | public ComponentType getType(); | /** | * The component ManagedObject. | * @return component ManagedObject. | */ | public ManagedObject getManagedObject(); | /** | * The deployment the component is associated with. | * @return component deployment. | */ | public ManagedDeployment getDeployment(); | } | | /** | * A simple type/subtype key for a ManagedComponent. Example | * type/subtypes include: DataSource/{XA,LocalTx,NoTX}, JMSDestination/{Queue,Topic}, | * EJB/{StatelessSession,StatefulSession,Entity,MDB}, MBean/{Standard,XMBean,Dynamic}, | * ... | * | * @author Scott.Stark(a)jboss.org | * @version $Revision:$ | */ | public class ComponentType | { | private String type; | private String subtype; | | public String getType() | { | return type; | } | public void setType(String type) | { | this.type = type; | } | | public String getSubtype() | { | return subtype; | } | public void setSubtype(String subtype) | { | this.subtype = subtype; | } | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005444#4005444 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005444

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: DataSource/ServiceXSLDeployer processing issue

by adrian＠jboss.org

"bill.burke(a)jboss.com" wrote : | I'd rather have each with their own bugs rather than a buggy generic solution that I have to keep backward compatibility with. | Well if you not interested in providing a generic solution then you shouldn't be discussing in the POJO Server forum. :-) And good luck on trying to persuade Scott to use the 20 different implementations of this feature from inside the profile service. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005383#4005383 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005383

19 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: JMS Example in 3.2 Beta

by tom.baeyens＠jboss.com

"jeffdelong" wrote : | 1) The JMSMessage Service is getting a ClassCastException when casting the lookup of java:/JmsXa to an XAConnectionFactory which should work and did work previously. | i don't recall this in the testing that i did. have you got any clues that could help me reproduce ? "jeffdelong" wrote : | 2) The NewProcessInstance command needs to set the variablesMap contained with the command. this is now added in cvs. thanks ! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005379#4005379 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4005379

19 years, 2 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 January 2007