[QA of JBoss Portal] - verifying webapp deployment
by mwringe
The test module uses cargo to deploy applications to a server, but it doesn't actually check if the web application has been deployed or not before continuing. This hasn't cause too many problems so far as Tomcat and JBoss seem to deploy things quickly enough. When moving to do tests on other containers, this is not always the case and this can cause tests to fail.
One solution for this would be to use cargo URLDeploymentMonitors to make sure that the web application is pingable before continuing (cargo uses this method to check when a server is started using the cargocpc.war).
This would require that all test web applications to not display a 404 page when its context is access.
Would this be an acceptable change to require all web applications to have a pingable context?
Note: ideally cargo would have some sort of other deployment monitor that could be used more transparently using the server logs, jmx, etc. But this is currently not the case.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153447#4153447
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153447
17 years, 10 months
[Design the new POJO MicroContainer] - Re: Alternative vfs jar implementation
by mstruk
jboss-vfs-alter branch now passes all the unit tests.
In AbstractVFSContextTest and FileVFSUnitTestCase I changed assertions that test URL equality. When ZipEntryContext is used URL schema changes, and those tests fail - I changed them so that only URL path part is compared.
In UnpackTestCase I changed some assertions since the previous ones test some implementation details that are different when it comes to ZipEntryContext. Ales, have a look, maybe we can put some more sensible tests there.
I also commited an optimization of the way file handles are released. I mentioned that it was too aggressive and causing a slight performance penalty. The slow down was not big, but was still noticable so I added an automatic asynchronous mechanism that releases files when they haven't been used for a few seconds. Currently this period is 5 seconds - hardcoded at the moment - can be made configurable. This fixes maybe about 80% of performance degradation which now looks to be ~1-2% jboss startup time relative to current vfs trunk.
I'm starting working on noCopy support now :)
Cheers,
- marko
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153428#4153428
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153428
17 years, 10 months
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Optimizing Pointcut Matching
by flavia.rainone@jboss.com
anonymous wrote : It should now be a matter of plugging it into the advisors so we only match what we need to match.
The BindingClassifier is plugged in the class advisor. However, my initial suggestion was a little different from what we have implemented. My suggestion consisted of keeping pointcuts classified into collections, so that it would be a matter of just retrieving the appropriate collection to perform the matching. Here is a piece of an e-mail I sent to the aop-dev list:
anonymous wrote : So, for example, when ClassAdvisor is building a chain for fieal read, it will do something like AspectManager.getFieldReadPointcuts(), or AspectManager.getPointcuts(PointcutType.FIELD_READ). It would match only those pointcuts to build the chains for field read joinpoints.
|
| To avoid incrementing the AspectManager interface too much, the methods added to AspectManager should be package protected. Another possibility would be adding a single method to AspectManager:
| PointcutCollection pointcuts = AspectManager.getPointcutCollection();
|
| Whereas PointcutCollection is a package-protected class, and this class would contain the methods to get all the specific pointcuts collection: getExecutionPointcuts, getFieldReadPointcuts, and so on. Notice that, whatever we add to AspectManager, can and should be package-proctected. So, the method above would be package-protected as well.
|
This approach would avoid the extra cost of doing an if statement for each binding to be matched. What do you think?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4153424#4153424
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4153424
17 years, 10 months