[Design of POJO Server] - Re: profile service, farming
by scott.stark＠jboss.org
Just some follow up comments since I'm currently testing the DeploymentManager api for adding raw deployment content to a repository.
So the first issue is that hot deployment is no longer really a scanner service as it was in the past. Such as service does exist, but its nothing more than a thread/executor that calls into the profile for the modified deployments. So 'hotdeployment' is purely a profile implementation detail, and how we reconcile local repositories across a cluster would be part of the org.jboss.profileservice.spi.DeploymentRepository.getModifiedDeployments() implementation. As we build out different repository implementation maybe we'll need to add more policy plugins for things like cluster synchronization.
Synchronization of multiple local file based repositories as you describe is difficult for something outside of the profile service as the exact state of a deployment is the raw deployment content + any admin edits that may have occurred. Raw content sitting on the disk may not be in the profile depending on what removing a deployment from a profile actually does.
The "Coordinating deployments" point is a bit confused in my view as there are a number of different aspects of a clustered application.
1) The simple notion of having a deployment available across all nodes in the cluster, the DeploymentPhase.APPLICATION_CLUSTERED notion of the DeploymentRepository. There could be an annotation for this down to a bean level rather than a coarse deployment level. We could support this using the MetaDataRepository levels and have a clustered MetaDataRepository where we just distributed the BeanMetaData(for example) for the annotated bean. Provided the deployers/deployment attachments were properly integrated with the MetaDataRepository, it should just work, but there is a dependency issue. I'm wondering if there really is a @Farmed vs a more expressive @Clustered notion though. I would think @Clustered could be a superset of @Farmed where if I only wanted distribution of a component across the cluster without any cluster aware aspects applied to the component. That type of farming/clustering seems outside of the scope of the profile service deployment repository. Its just a metadata/metadata repository issue.
2) Cluster wide dependencies between beans. Dependencies on components that are marked as @Clustered needs a cluster aware dependency implementation. Custom dependencies are supported by the mc, but the component deployers generating the component metadata have to generate the correct dependency implementation.
3) Clustered aware aspects. Caches, proxies, cluster-wide singletons, are behaviors that you potentially want cluster aware implementations of for components marked as @Clustered.
Clustering like security is a cross cutting notion that we need the proper metadata for, and hooks to which cluster aware variations of the aspects can be applied. I agree that cluster aware deployers should not be needed. Rather, the deployer should be driven off of the metadata and component aspects to create clustered components. Identifying these aspects and making sure deployers just work when the cluster aware aspects are configured is the main task.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152811#4152811
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152811
18 years
[Design the new POJO MicroContainer] - Re: Alternative vfs jar implementation
by mstruk
Ok ... I fixed most of the unit test failures (not yet commited). There is one remaining category of failing tests that I need an opinion about.
My ZipEntryContext rewrites a URL used to create it to always have vfszip: schema in order to ensure proper handling when accessing via URL. There are now 7 tests failing with variations of this issue:
ERROR: junit.framework.AssertionFailedError: expected:<vfsfile:/C:/Users/Devel/svnroot/jboss-vfs-alter/some.jar> but was:<vfszip:/C:/Users/Devel/svnroot/jboss-vfs-alter/some.jar>
A schema mismatch.
What happens here is that vfs context is created on directory. Then findChild() is called to get a jar child. It's expected that child's URL is directory URL + '/' + childName. But in this case child is a mount point of ZipEntryContext into FileSystemContext and has a different URL schema.
The question is if this expectation is part of the contract, and if it has some specific use-case behind it.
Seems to me that VirtualFileHandler.toURL() should be free to return whatever as long as the URL leads to a correct virtual file.
I would go and fix these tests to compare URL file part, but not schema. Does that sound ok?
cheers,
- marko
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152809#4152809
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152809
18 years