October 2006 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Structure deployer changes comitted to trunk

by scott.stark＠jboss.org

"kabir.khan(a)jboss.com" wrote : | For the aop tests I am seeing a couple of problems where nested .aop files are ignored. The classes in the .aop files are not added to the classpath resulting in NoClassDefFoundErrors and the META-INF/jboss-aop.xml files are not picked up. | | If I deploy a sar which has a nested .aop file, the sub deployments are no longer passed in to the deployers. These are deployed in the testsuite, and so are deployed via a MainDeployer.deploy(). | | If I put the sar in the deploy folder and then start up jboss, both the sar and the nested .aop file get picked up. | | The sar and aop files are packed | I have fixed the remote deployment issue, and the structure is correct in terms of the DeploymentContexts. I am seeing an error I don't see when the sar is deployed in deploy though: | 23:13:19,874 WARN [AspectManagerServiceJDK5] EnableTransformer has been deprecated, please use EnableLoadtimeWeaving. See docs for more details | 23:13:19,898 WARN [MainDeployer] undeploy 'file:/home/svn/JBossHead/jboss-head/testsuite/output/lib/aop-extendertest.sar' : package not deployed | 23:13:19,899 INFO [MainDeployer] deploy, url=file:/home/svn/JBossHead/jboss-head/testsuite/output/lib/aop-extendertest.sar | 23:13:59,355 ERROR [AbstractKernelController] Error installing to Instantiated: name=jboss.aop:name=ExtenderTester state=Described mode=Manual requiredState=Configured | org.jboss.deployment.DeploymentException: Unable to createMBean for jboss.aop:name=ExtenderTester | Can you look at that and let me know what is different. You need the mc snapshot jar updates I just committed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981227#3981227 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981227

19 years, 5 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Do we have a problem with Synchronous channel?

by clebert.suconic＠jboss.com

I think there is a problem with JGroups configuration while testing this. I hope this is not something specific on my computer. If someone else could test this. syncRequests are not being received on nodeB for some reason. Even changing PostOfficeRequestHandler::handle to verbose on messages, I never get any message received. | private class PostOfficeRequestHandler implements RequestHandler | { | public Object handle(Message message) | { | System.out.println("***************Request handler**************"); | if (trace) { log.info(nodeId + " received message " + message + " on sync channel"); } | try | { | byte[] bytes = message.getBuffer(); | | ClusterRequest request = readRequest(bytes); | | Object result = request.execute(DefaultClusteredPostOffice.this); | | return result; | } | catch (Throwable e) | { | log.error("Caught Exception in RequestHandler", e); | IllegalStateException e2 = new IllegalStateException(e.getMessage()); | e2.setStackTrace(e.getStackTrace()); | throw e2; | } | } | } | getState() is working fine through synchronous channel. Assync is also working fine, but not sync. I was having problems on finding new binding over the cluster and this was the problem. Clebert Suconic View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981198#3981198 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981198

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - SuffixMatchFilter default VisitorAttributes does not make se

by scott.stark＠jboss.org

A hangover from the isArchive removal is that the default VisitorAttributes.RECURSE_LEAVES_ONLY used by the org.jboss.virtual.plugins.vfs.helpers.SuffixMatchFilter don't work for "archives" (.jar, .sar, ... java archives, be they zip files or directories). This simple code usage: | SuffixMatchFilter earLibFilter = SuffixMatchFilter(".jar"); | List<VirtualFile> archives = lib.getChildren(earLibFilter); | results in no .jar files being found, even though they exist. The reason is that .jar files are directories, and only visiting leaves means they are not visited. They are in fact traversed for leaves to visit, and this is also not a default desired behavior, at least for this example usage. For this usage what we want is the VisitorAttributes.DEFAULT, which is to visit both leaves/non-leaves and not to recurse. I would say that this should be the default VisitorAttributes used. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981188#3981188 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981188

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: EARStructure not deploying modules

by scott.stark＠jboss.org

Not producing ContextInfos. This code: | if (scan) | { | JARCandidateStructureVisitorFactory factory = new JARCandidateStructureVisitorFactory(); | final J2eeApplicationMetaData my = metaData; | factory.setFilter(new VirtualFileFilter() { | public boolean accepts(VirtualFile file) | { | if (my.hasModule(file.getName())) return false; | return true; | } | }); | VirtualFileVisitor visitor = factory.createVisitor(context, null); | root.visit(visitor); | } | would need to be ported to create ContextInfos. I also do not see where the J2eeApplicationMetaData is created in the first placed based on annotations. The only place there the J2eeApplicationMetaData is populated is when its imported from the xml descriptors. If the J2eeApplicationMetaData has the module, there is no reason to scan so this looks like circular code to me. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981184#3981184 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981184

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: EARStructure not deploying modules

by bill.burke＠jboss.com

I thought I already had this working in the old code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981180#3981180 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981180

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: EARStructure not deploying modules

by scott.stark＠jboss.org

The one place where we still might need some enhancement is a notion of options/properties at the ContextInfo level. We are currently throwing away information like what structure deployer produced a given ContextInfo. We may want additional attributes like: type=jsr77 type or deployer type in terms of structure name=an alternate name for a context. This could be used to build a structure tree graph that has names different than the raw vfs paths. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981171#3981171 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981171

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: EARStructure not deploying modules

by scott.stark＠jboss.org

The other place where the visitor pattern used by addAllChildren could be applied is to the not-yet-implemented ear scanning behavior in the absence of an application.xml. Maybe you can look at implementing that? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981162#3981162 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981162

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: EARStructure not deploying modules

by scott.stark＠jboss.org

"bill.burke(a)jboss.com" wrote : | Ok, i stepped through the CandidateVisitor code and it is making sense now. | | 1. I think there is a catch 22 in the current code. The CandidateVisitor will not determineStructure if the ContextInfo already exists in the StructureMetaData. StructureMetaData does not set the correct parent (and TreeSet order) until a parent has been added. Get me? | the current candidate visitor is still too much of a port from the old DeploymentContext notion. One thing we are doing away with is the notion of a "candidate' as is, I'm not sure if this really is a deployment notion. The only things that show up in the StructureMetaData are ContextInfos for something that was recognized. If a deployer allows subdeployments that are not of the type it recognizes, then it delegates to the input deployers to identify the subdeployments. We just need to get the legacy visitor notions working correctly. "bill.burke(a)jboss.com" wrote : | 2. Since the EAR knows the structure of its subdeployments and what virtual files should be candidates, shouldn't it locate candidates and determine their structure rather than delegate it to addAllChildren method that curently exists? | An ear structure deployer only has partial knowledge of its structure. Namely its lib classpath and what should be considered as possible subdeployments. Yes, it should build the ContextInfo for the ear itself and set the ear lib classpath, and then it should call deployers.determineStructure(moduleFile, metaData, deployers) to validate that the declared ear module file is in fact valid structurally. This is all addAllChildren(VirtualFile parent, StructureMetaData metaData, StructuredDeployers deployers) should be doing though. I have not walked through the catch22 you mentioned to really understand it, but I'm sure its just inconsistent legacy behavior. Its possible that the addAllChildren method should just be dropped since the deployers is all that is likely needed. The only reason I can see keeping it would be for the additional filter notion in the case that a containing deployer wanted to restrict the accepted sub-subdeployments, or maybe externalize the filter for subdeployments. "bill.burke(a)jboss.com" wrote : | Are you finishing this code? I think I know what needs to be done now. | Yes, I'm working on it. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981160#3981160 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981160

19 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: status of merge, non persisted script on fork, and n-out

by brittm

Ronald, I put a solution into the contributions section that addresses pattern 6 and 14. http://wiki.jboss.org/wiki/Wiki.jsp?page=MultiChoiceForkAH While it may be overkill for what your doing, you might be able to get some use out of it. Now that I think about it, I really need to update that--I've added some functionality since I posted it. -Britt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981155#3981155 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981155

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: EARStructure not deploying modules

by bill.burke＠jboss.com

"scott.stark(a)jboss.org" wrote : "bill.burke(a)jboss.com" wrote : | | addAllChildren isn't the way to go because the ear only deploys those things at the top level or those deployed in application.xml ... plus ... jars in the lib/ directory (for JPA). | | | | So, why did you remove the code in the old EarStructure code that I wrote that created DeploymentContexts? WHo is responsible for creating the deployment contexts in the EAR and determining their structure? | | | | I am really confused on WTF is going on. It was pretty clear before, but with this structure metadata it is not anymore... | | | | | I said an addAllChildren that started at each file listed in the ear modules. The DeploymentContext is a mix of structure info and runtime metadata like the object models for ear descriptors. The StructureMetaData is to describe exactly what contexts in the vfs should be treated as deployment contexts, what the context classpaths are, and what the parent child relationships are. That is input to the MainDeployer to initiate the runtime deployment where the metadata can be obtained from the DeploymentContexts (created by the MainDeployer.StructureBuilder) using the associated virtual file and classpath info. | Ok, i stepped through the CandidateVisitor code and it is making sense now. 1. I think there is a catch 22 in the current code. The CandidateVisitor will not determineStructure if the ContextInfo already exists in the StructureMetaData. StructureMetaData does not set the correct parent (and TreeSet order) until a parent has been added. Get me? 2. Since the EAR knows the structure of its subdeployments and what virtual files should be candidates, shouldn't it locate candidates and determine their structure rather than delegate it to addAllChildren method that curently exists? Are you finishing this code? I think I know what needs to be done now. Thanks for being patient. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981154#3981154 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981154

19 years, 5 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 October 2006