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

[Design the new POJO MicroContainer] - Deployment redeploy

by alesj

After spending a day on figuring out why my jboss-minimal-tests are not working as they should I also stumbled upon a question what happens if metadata changes? I remember I had previous discussion about this with Scott. I even found TODO (which is probably my) in - http://anonsvn.jboss.org/repos/jbossas/trunk/system/src/main/org/jboss/sy... But I can see I never given it enough of thought, since I only yesterday saw that we're missing all this functionality in deployers. Why 'missing all this functionality in deployers'? Since in order for a client to know if the metadata has been changed, it needs to know where metadata resides, but that's is server side (structure) detail. So this is what I came up with. Few pseudo code lines. The entry point to all should of course be - as for all other deployment things - DeployerClient: | // deleted, modified, nothing | ModifcationType getModificationType(); | First we need to know if client slide Deployment still exists: | boolean exists(); | which for VFSDeployment it would check if the root still exists. Then we need to get server side representation of deployment - DeploymentContext. And recursively check it is was modified. | if (deploymentContext.isModified()) | return true; | | List<DeploymentContext> chidren = deploymentContext.getChildre(); | for (DeploymentContext child : children) | return checkModified(child); | Probably in case of VFSDeploymentContext we will check the root and metadata locations. So at the end, impl in MainDeployerImpl would look like | ModificationType getModificationType(Deployment deployment) | { | if (deployment.exists() == false) | return DELETED; | | DeploymentContext context = getContext(deployment); | if (context.isModified()) | return MODIFIED; | else | return NONE; | } | (OK, bunch of assert checks missing, but we get the picture :-)) So ProfileImpl would then simply call this method to see which deployment need to be handled. Sounds OK? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156291#4156291 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156291

17 years, 10 months

1
0
0 / 0

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

by alesj

"adrian(a)jboss.org" wrote : | 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; | | } | | | Similar code would be required for getAnnotations() If we're about to do this, then it should be done on AnnotationItem, since annotations can also come from MetaData::get(Local)MetaData(s). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156275#4156275 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156275

17 years, 10 months

1
0
0 / 0

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

by alesj

"scott.stark(a)jboss.org" wrote : Right, I don't think Replaceable is sufficient. | So, should I still add this to MDR or not? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156266#4156266 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156266

17 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Cannot build jbpm3/tags/jpdl_3_2_2

by tom.baeyens＠jboss.com

you just got commit rights :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156257#4156257 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156257

17 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: JBoss Cache Public API

by manik.surtani＠jboss.com

"genman" wrote : Removing type parameters seems like a good idea. Agreed, but I'd want to see to what degree this will affect backward compatibility. E.g., how many folk have written code to make use of this in 2.X. "genman" wrote : | Something to consider would be to change the Node interface to return live references, e.g. "Cache.getNode(x).getData()" would return a Map whose operations affect the in-cache state. So a "getData().clear()" would clear the node data. I'm not sure how well this would work. It may be poorly performing. | Could be poor performing if it has to be by way of a proxy map (which would then make calls up and down the interceptor chain to ensure locking, loading, etc.). But I like the "usability" implications. "genman" wrote : | I created a "Caches" utility/factory object a long time ago that created java.util.Map instances backed by JBoss Cache and it'd be interesting if something like that were endorsed. | It (or something very similar) certainly will be in 3.X. I think there is a lot of value in a "flat map" interface, especially since this plays into JSR107 nicely. "genman" wrote : | I would suggest changing the CacheLoader interface. | | Remove these methods: | | | Object put(Fqn name, Object key, Object value) throws Exception; | | Object remove(Fqn fqn, Object key) throws Exception; | | | These are low-performing operations on many CacheLoaders implementations. | | Also I would remove | | | void put(Fqn name, Map<Object, Object> attributes) throws Exception; | | | and replace the put operation with: | | | void replaceAll(Fqn name, Map<Object, Object> attributes) throws Exception; | | | | Remove methods that are redundant: | | | void loadEntireState(ObjectOutputStream os) throws Exception; | | void storeEntireState(ObjectInputStream is) throws Exception; | | | (Though their removal is probably not critical.) | * put/remove and replaceAll - makes sense, but may be a case of "change for change's sake" since most cache loader impl's would actually do something like what you suggested internally anyway. * load/store state - this is needed to be able to stream state from one cache loader to another. Deserializing everything and then calling replaceAll() may be unnecessarily expensive if the CLs can have an internal mechanism of working with the streams directly. "genman" wrote : | Also, I'd take a look at how Hibernate uses JBoss Cache 2. It seems there's a bunch of "util" methods that might make sense to carry over. One thing that comes to mind is the use case of storing a single item in a Node. Maybe create a "key" singleton object? Something like this already exists - JBCACHE-1082. Needs to be worked in to the codebase, properly profiled and optimised though. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156246#4156246 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156246

17 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Cannot build jbpm3/tags/jpdl_3_2_2

by thomas.diesler＠jboss.com

The build should fail saying just that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156242#4156242 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156242

17 years, 10 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Optimizing Pointcut Matching

by kabir.khan＠jboss.com

If this can be made so that the bindings are applied in the same order as the current "unsorted" way that's fine. That could probably work by for example *all "methodexecution" and "all" bindings are added to the "methodexecution" collextion *all "field", "all" and "set" bindings are added to the "set" collection etc. Although, this might get a bit complicated when using sub-domains? Take a look at Domain.getBindings() and see if you can come up with something there View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156235#4156235 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156235

17 years, 10 months

1
0
0 / 0

[Design of EJB 3.0] - Re: Instructions for SerializableMethod Unit Tests

by jaikiran

Thanks Andrew. This should be enough to get started with the testcase. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156232#4156232 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156232

17 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Emma required on client

by timfox

Ok, got it. Maybe we should make sure ant distro automatically does a clean first? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156219#4156219 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156219

17 years, 10 months

1
0
0 / 0

[Design of EJB 3.0] - Re: trunk Ejb3Deployment is incompatible with jbossas trunk

by wolfc

The constructor should be reinstated. It's not allowed to throw backwards compatibility out the door just like that. The old constructor should use some transitional code to call upon the new constructor (preferably with some deprecation warnings). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4156218#4156218 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4156218

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