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

[Design of POJO Server] - Re: Metadata view with system properties resolved

by scott.stark＠jboss.org

Right, we don't produce a merged view that replaces the system properties similar to how we merge annotations and xml metadata. We will run into issues with xml metadata with system property references being translated into pojo metadata that has the property resolved to a value that will no longer be updated if the system property changes. In the meta type management view of the property we should be displaying the property value/type as a SystemPropertyMetaValue/MetaType. How to keep the profile service metadata referencing the system property and creating a system property replaced view is the question. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155778#4155778 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155778

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by scott.stark＠jboss.org

"bstansberry(a)jboss.com" wrote : "scott.stark(a)jboss.org" wrote : Is the APPLICATION_CLUSTERED phase going to be useful? | | I'm thinking not. Seems like the concept was serving two functions: | | 1) Dealing with a profile service bootstrap dependency issue (i.e. can't do intra-cluster communications until the APPLICATION phase clustering services are available). We've eliminated that by deciding that a clustered profile service impl will have a channel as part of its bootstrap. | | 2) It was a sort of hard-coded marker for a clustered sub-profile. Right. So I am going to change APPLICATION_CLUSTERED to APPLICATION_TRANSIENT and you can use that for the hasingleton scanner. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155774#4155774 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155774

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by adrian＠jboss.org

"bstansberry(a)jboss.com" wrote : | Interesting thing to me about this is for JEE components it allows a fast activation following ha singleton failover, since the service is 90+% ready to go when the node becomes master. As long the components are written to respond to the activate() callback and not the start() callback. i.e. the container is created but its frontend isn't bound into jndi or linked as a valid web context etc. That's certainly a better semantic for the valve/redeploy processing since it almost becomes an atomic swap/failover instead of waiting for the full undeploy/deploy cycle. But there's many other issues to resolve before we can get there, e.g. not using the default "big ball of mud" classloading configuration :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155773#4155773 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155773

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by adrian＠jboss.org

"bstansberry(a)jboss.com" wrote : | Essentially we're talking about another step in the lifecycle -- create/start/activate/deactivate/stop/destroy that all containers would have to support. | I don't really see it as a true lifecycle step since you're NOT waiting to resolve a dependency. The context is in a valid final state, its just inactive. I suppose you could see it as an alternative to the "Installed" state, e..g InstalledInactive and InstalledActive could be alternate states with some processing going on when it switches between the states. But the transistion is decided by some arbitrary notiifcation, not a dependency (unless you count the dependency on oneself being installed :-) anonymous wrote : | Thinking a bit about whether that maps to the "valve" concept where (AIUI) a component is brought all the way to DeploymentStage.REAL and in a final change to DeploymentStage.INSTALLED external things like JNDI refs, request pipelines etc are switched. | It certainly relates to the valve, but the valve mainly involves tracking and waiting for requests to complete. Again this could be considered a different state where you allow old requests but hold/deny new ones. A sort of "InstalledDeactivating" state. ;-) Whether we would actually implement it that way, is a different issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155770#4155770 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155770

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Metadata view with system properties resolved

by bstansberry＠jboss.com

>From another thread: "adrian(a)jboss.org" wrote : | "bstansberry(a)jboss.com" wrote : | | OT: Is there a general automagic facility/utility yet for doing String property replacement when populating metadata? For org.jboss.ejb3.annotation.clustered there's still manual code that does the property replacement. | | You'll have to explain what you mean on a different thread. | | If I understand correctly ... | I don't think its possible in general since in most cases | MetaData.getAnnotation() will just be returning Class.getAnnotation() | which is immutable, its a jdk object and | we don't "intercept" the fine grained Clustered.partition() invocation. | My question was quite confused. :( Not about populating metadata at all. The issue is more one of having a mechanism that provides a view on metadata where system property references are resolved. Basically an aspect that does the system property resolution on read operations on a metadata object. AIUI, right now JBossXB can resolve system properties when populating a metadata object. But if you do that you lose the original underlying value. And if the metadata object is backed by an annotation, JBossXB doesn't come into play. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155768#4155768 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155768

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by bstansberry＠jboss.com

Re: the property replacement, yeah, my question wasn't clear. I'll open another thread. "adrian(a)jboss.org" wrote : That's why I suggested a jboss-activation.xml to try to make it easier to manage. The downside is it pushes the responsibility of this new metadata to the subsystems to read it, since only they know what it means to activate their fine-grained component. Essentially we're talking about another step in the lifecycle -- create/start/activate/deactivate/stop/destroy that all containers would have to support. Thinking a bit about whether that maps to the "valve" concept where (AIUI) a component is brought all the way to DeploymentStage.REAL and in a final change to DeploymentStage.INSTALLED external things like JNDI refs, request pipelines etc are switched. Interesting thing to me about this is for JEE components it allows a fast activation following ha singleton failover, since the service is 90+% ready to go when the node becomes master. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155764#4155764 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155764

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | You'll have to explain what you mean on a different thread. | I started a thread here: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155761#4155761 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155762#4155762 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155762

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Replacing system properties in metadata

by adrian＠jboss.org

Brian asked on another thread about automatically replacing system properties on annotations. First, I suppose if we were going to do this, it would need a meta annotation to trigger the behaviour otherwise it would be doing a lot of work unnecessarily. e.g. | @org.jboss.metadata.spi.Replaceable | public @interface Clustered | { | String partition() default = "${jboss.parition.name:DefaultDomain"; | } | Then we could add something to MetaDataRetrievalToMetaDataBridge that does the replacement, e.g. | | public <T extends Annotation> T getAnnotation(Class<T> annotationType) | { | if (annotationType == null) | throw new IllegalArgumentException("Null annotationType"); | AnnotationItem<T> item = retrieval.retrieveAnnotation(annotationType); | if (item == null) | return null; | - return item.getValue(); | + T result = item.getValue(); | + if (annotationType.hasAnnotation(Replaceable.class)) | + result = checkReplaceable(result); | + return result; | } | Where checkReplaceable() either 1) creates a new annotation from the original one with system properties replaced. 2) wraps the annotation in a dynamic proxy that implements the annotation interface and does the replacement lazily Similar code would be required for getAnnotations() View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155761#4155761 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155761

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by adrian＠jboss.org

"bstansberry(a)jboss.com" wrote : | OT: Is there a general automagic facility/utility yet for doing String property replacement when populating metadata? For org.jboss.ejb3.annotation.clustered there's still manual code that does the property replacement. You'll have to explain what you mean on a different thread. If I understand correctly ... I don't think its possible in general since in most cases MetaData.getAnnotation() will just be returning Class.getAnnotation() which is immutable, its a jdk object and we don't "intercept" the fine grained Clustered.partition() invocation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155759#4155759 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155759

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by bstansberry＠jboss.com

Something ate part of my first version. Should have been: | @Target(ElementType.TYPE) | @Retention(RetentionPolicy.RUNTIME) | public @interface HASingleton | { | String partition() default "${jboss.partition.name:DefaultPartition}"; | | /** | * Position in the current view that defines the singleton master. | * 0 means the oldest node, 1 means 2nd oldest, ... | * -1 means the youngest node, -2 means 2nd youngest, ... | */ | int position() default 0; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155752#4155752 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155752

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 June 2008