[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
18 years
[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
18 years
[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
18 years