[Design of POJO Server] - Re: AbstractDeploymentUnit.getMetaDataFiles()
by scott.stark@jboss.org
"bill.burke(a)jboss.com" wrote : "scott.stark(a)jboss.org" wrote : I have always thought jar urls were fundamentally flawed since they never have dealt with nested jars, and mix content with another protocol. Its also not really a protocol issue. I would like jar urls to disappear and whether or not a file was a compressed archive be a detail of the VFS.
| |
|
| That's great you want to do this, but various SPIs in JavaEE5 require passing valid URLs. I'm running into this problem right now with nested jars within an EAR. PU need to pass in URL of the persistence.xml file but it is fucked up URL:
|
| jar:file:/.../foo.ear!/ejb.jar/META-INF/persistence.xml
|
| URL handler tries to open ejb.jar/META-INF/persistence.xml as a JarEntry within foo.ear (which its not obviously)
|
| Are we going to do:
|
| vfs:file:/.../foo.ear/ejb.jar/META-INF/persistence.xml?
|
| Is this something I can work on please as it is blocking me.
|
| Thanks,
|
| Bill
Its something you can work on now that the structural deployer related vfs issues have been done. Instead of going with another nested url syntax, we may want:
vfs-file:/.../foo.ear/ejb.jar/META-INF/persistence.xml
so that URL/URI accessors like getPath, getHost, etc. work. They don't work with opaque url syntaxes.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979465#3979465
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979465
19 years, 5 months
[Design of POJO Server] - jboss-head updated for vfs changes
by scott.stark@jboss.org
jboss5 trunk has been updated for VFS changes to the visitor recursion and isAttribute removal.
Code that previously was using VisitorAttributes.setRecurseArchives(false):
| VisitorAttributes va = new VisitorAttributes();
| va.setRecurse(true);
| va.setLeavesOnly(true);
| va.setRecurseArchives(false);
| FilterVirtualFileVisitor visitor = new FilterVirtualFileVisitor(filter, va);
|
Now needs to specify a recursion filter. To exclude known jar achive suffixes the following can be done:
| VisitorAttributes va = new VisitorAttributes();
| va.setLeavesOnly(true);
| SuffixesExcludeFilter noJars = new SuffixesExcludeFilter(JarUtils.getSuffixes());
| va.setRecurseFilter(noJars);
| FilterVirtualFileVisitor visitor = new FilterVirtualFileVisitor(filter, va);
|
The server is booting fine with these changes. I'm still validating that there is no extra recursion/components being created because of these changes.
The next refactoring I'm testing is the structural deployer changes to produce a StructuredMetaData object rather than DeploymentContexts.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979462#3979462
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979462
19 years, 5 months
[Design of JBossCache] - Re: POJOization of config elements
by bstansberry@jboss.com
anonymous wrote :
| Why doesn't the standard BL impl we ship with (there is only one) also come with a BLC subclass, could be a good example since Properties are ugly and we don't really want to promote that mechanism anyway?
|
I've written one. Also, the same pattern applies to CacheLoaders (substitute CacheLoaderConfig for BuddyReplicationConfig and IndividualCacheLoaderConfig for BuddyLocatorConfig.) I've got specific IndividualCacheLoaderConfig subclasses created for all the standard CacheLoader impls as well.
anonymous wrote :
| Why do we need to support Properties anyway, for 2.0.0 we don't need to be backward-compat ...
|
We still want to support creation of a config using the old 1.x format and XmlConfigurationParser, don't we? Otherwise we require use of the MC and a -beans.xml file, even outside the AS. The XmlConfigurationParser approach can't handle arbitrary sets of XML elements (at least not without a lot of work), hence the use of Properties as a workaround.
Even if we decide to require use of the MC in 2.0.0.GA, leaving in Properties support for now makes it easier to transition. We can strip it out later (e.g. after alpha).
FYI, I've been proceeding along the lines discussed on this thread trying to see if there are problems. Here's where it stands:
1) Custom config classes created for all NextMemberBuddyLocator, and all the CacheLoader impls, and impls designed to use them.
2) AFAICT, there are no testsuite regressions using this code (i.e. all the existing tests that use properties for configuration pass. The various config classes all know how to convert from the Properties format to POJO properties, so the existing testsuite is excercising this stuff fairly well.
TODO:
1) Continue discussion.
2) If it sounds good, continue along same lines with eviction policies. This might be easier, as it looks like the eviction policy config is already somewhat done along these lines; e.g. a lot of specialized config classes exist.
2) Set up -beans.xml files for use in the AS to test building the standard cache configs used in the AS. That's provides a basic test of the MC approach.
3) Round out the JBC test suite with more formal tests of the MC approach. I'd say that can be done post-alpha.
How's that sound?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3979455#3979455
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3979455
19 years, 5 months