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

[Design of POJO Server] - Re: deployers/metadata-beans.xml

by scott.stark＠jboss.org

Ok, I'll see what is up when the name is changed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152812#4152812 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152812

17 years, 7 months

1
0
0 / 0

[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

17 years, 7 months

1
0
0 / 0

[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

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: deployers/metadata-beans.xml

by anil.saldhana＠jboss.com

I meant all the other beans.xml in the deployers directory had the format xxx-deployer-beans.xml (consistency). I should have noticed that one of the beans was commented out. My bad. If you rename the file to metadata-deployer-beans.xml, then you see the error that the beans are already installed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152805#4152805 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152805

17 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1062 and metadata

by ALRubinger

I still think we should be checking @Remote and @Local within jboss-metadata to ensure they're valid business interfaces. Opposing opinions anyone? Remember backwards-compat with EJB3 RCx for AS 4.2.x is out the window. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152804#4152804 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152804

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Re: deployers/metadata-beans.xml

by scott.stark＠jboss.org

The ReferenceMetaDataResolverDeployer has one commented out, and the current implementation uncommented. Since the newer impl has been in use for a while I have deleted the old impl. I don't follow what you mean by name consistency. It sounds like a missing dependency problem. What name would show this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152803#4152803 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152803

17 years, 7 months

1
0
0 / 0

[Design of POJO Server] - deployers/metadata-beans.xml

by anil.saldhana＠jboss.com

http://jira.jboss.com/jira/browse/JBAS-5544 This file needs to be renamed to be consistent. Additionally, there are cases of beans with same names. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152799#4152799 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152799

17 years, 7 months

1
0
0 / 0

[Design of JBoss Build System] - Re: maven-buildmagic-thirdparty-plugin won't pickup source f

by pgier

No, the app server is depending on this one instead: org.jboss.aop:jboss-standalone-aspect-library-jdk50 I think they are the same jar except that jboss-aop was built with maven and jboss-standalone-aspect-library-jdk50 was built with ant. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152759#4152759 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152759

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Composite Map key and weak reference

by bstansberry＠jboss.com

I just wrapped them in WeakRefs in case they would leak the Class' classloader, preventing gc of the Class. Don't know whether in your scenario they will or not. TBH, I didn't think much at all about the annotations; I was focused on the Class; just threw in the annotation array because you said your key had one. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152730#4152730 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152730

17 years, 7 months

1
0
0 / 0

[Design of JBoss Build System] - Re: maven-buildmagic-thirdparty-plugin won't pickup source f

by scott.stark＠jboss.org

There are source under the maven svn repo for this version though, https://svn.jboss.org/repos/repository.jboss.org/maven2/org/jboss/aop/jbo... | # jboss-aop-2.0.0.CR9-sources.jar | # jboss-aop-2.0.0.CR9-sources.jar.md5 | # jboss-aop-2.0.0.CR9-sources.jar.sha1 | # jboss-aop-2.0.0.CR9.jar | # jboss-aop-2.0.0.CR9.jar.md5 | # jboss-aop-2.0.0.CR9.jar.sha1 | # jboss-aop-2.0.0.CR9.pom | # jboss-aop-2.0.0.CR9.pom.md5 | # jboss-aop-2.0.0.CR9.pom.sha1 | Isn't that where the thirdparty contents are coming from? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152720#4152720 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152720

17 years, 7 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 May 2008