Hudson build became unstable: Synapse - Trunk » Apache Synapse - Transports #483
See http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/org.apache.synapse$synapse-transports/483/ - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Commented: (SYNAPSE-519) Cant start synapse using synapse war
[ https://issues.apache.org/jira/browse/SYNAPSE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682568#action_12682568 ] Charith Dhanushka Wickramarachchi commented on SYNAPSE-519: --- Hi , since synapse.war --> WEB-INF/lib does not contain some of the dependencies defined in the parent pom (which is needed to start synapse ). I had to explicitly define them in the war modules pom. if there is a better way to do it please suggest. thank you, Charith > Cant start synapse using synapse war > > > Key: SYNAPSE-519 > URL: https://issues.apache.org/jira/browse/SYNAPSE-519 > Project: Synapse > Issue Type: Bug > Components: Deployment >Affects Versions: 1.3 > Environment: Ubuntu 8.10 >Reporter: Charith Dhanushka Wickramarachchi >Priority: Blocker > Attachments: patch.txt, patch.txt > > > when trying to start synapse using synapse.war there is a fatal massage > coming synapse home is not set > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Updated: (SYNAPSE-520) Issue when security different security policies are applied to a proxy service and an associated endpoint
[ https://issues.apache.org/jira/browse/SYNAPSE-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nandana Mihindukulasooriya updated SYNAPSE-520: --- Attachment: SYNAPSE-520.patch Patch to resolve the issue. thanks, Nandana > Issue when security different security policies are applied to a proxy > service and an associated endpoint > - > > Key: SYNAPSE-520 > URL: https://issues.apache.org/jira/browse/SYNAPSE-520 > Project: Synapse > Issue Type: Bug >Reporter: Nandana Mihindukulasooriya > Attachments: SYNAPSE-520.patch > > > Scenario > Client --- secure (policy A) --> proxy service -- secure (policy B) --> real > service > Problem : > Wrong policy is picked in the return path. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Created: (SYNAPSE-520) Issue when security different security policies are applied to a proxy service and an associated endpoint
Issue when security different security policies are applied to a proxy service and an associated endpoint - Key: SYNAPSE-520 URL: https://issues.apache.org/jira/browse/SYNAPSE-520 Project: Synapse Issue Type: Bug Reporter: Nandana Mihindukulasooriya Scenario Client --- secure (policy A) --> proxy service -- secure (policy B) --> real service Problem : Wrong policy is picked in the return path. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: svn commit: r753144 - in /synapse/trunk/java/modules: core/src/main/java/org/apache/synapse/mediators/builtin/ core/src/main/java/org/apache/synapse/mediators/db/ core/src/main/java/org/apache/s
Andreas I agree with you. It is my fault that setting empty methods. But, I never did it for enforce any things, It was happened with my changes to remove two ‘init’ methods(Only concern was removing tow init methods ). I didn’t care it until this thread begins. Definitely, it may require substantial changes. But, if something needs to be correct, then it should do at some point. If community like for changes, we need to do. I may not able to take responsibly at this stage as I can’t guarantee allocating time. One thing, I have to fix some jiras and statistic collection functionally. Other thing, I am always busy during these days due to education related things. It is great if you can do this (if you have time and community too like these changes) Thanks Indika On Tue, Mar 17, 2009 at 4:13 AM, Andreas Veithen wrote: > Indika, > > I still fail to see how the fact that AbstractMediator implements > ManagedLifecycle (with empty default implementations for init and > destroy) is enforcing anything. What is the improvement compared with > the situation before? > > On the other hand, I agree with you that the issues related to > mediator lifecycle management that we have seen in the past are (or at > least could be seen as) an indication of a flaw in the design. Indeed, > one attribute of a good design or architecture is that it enforces > things and prevents people from implementing things in the wrong way. > > From the issues we have seen in the past, I would identify two > problems with the current lifecycle management: > > 1. We rely on the fact that mediators having child sequences (list > mediators, switch-case, etc.) are able to correctly manage the > lifecycle of their child mediators. We have seen examples in the past > where this wasn't the case. > > 2. We will sooner or later run into problems where during > initialization, one managed object tries to interact with another > managed object that has not yet been initialized. (This is the typical > problem that arises with managed objects) > > If we want to avoid these issues, then we should use (or should have > used) another pattern: Register all managed objects in a central place > as soon as they are created. Note that in case of mediators, this > would require some sort of configuration context to be passed around > to MediatorFactory implementations and to MediatorFactoryFinder > (getMediator in particular). Instead of initializing the managed > objects recursively as described above, one would then simply > initialize all the registered objects sequentially. This solves issue > 1 and enforces lifecycle management because the only place where a > mediator can be created is MediatorFactoryFinder#getMediator and that > method would require the configuration context. The pattern could also > be used to solve issue 2 because one could postpone the initialization > of a managed object if it fails due to some uninitialized dependency. > > The problem with all this is that it would require some substantial > changes that will break existing code... > > Regards, > > Andreas > > On Mon, Mar 16, 2009 at 17:53, indika kumara wrote: >> Hi All >> >> Just now had a time to look at this. >> >> Actually what I did from commit say by my commit log ‘remove >> ManagedLifecycle from mediators that extends AbstractMediator as >> AbstractMediator already implements ManagedLifecycle’. Actually, I >> just replied to the thread as I have to replay as this related with >> me. I just want to get rid if this thread as I had many works to do >> and I really don’t care other things, when I have important things to >> do. >> >> I am trying to take design decision on this and I expect to get answer >> for these. >> >> 1) Is ‘ManagedLifecycle’ is a trick to allow mediators and others to >> do require work related with initialization and destroy. Currently, I >> can see only this as a trick. Trick is still worked. >> 2) Otherwise…. Synapse initiators came up with great set of >> abstractions such as mediators, endpoints, tasks, registry, etc to >> build an ESB using these abstractions. Then, they have thought that >> these abstractions should be properly managed. Therefore, came up with >> a new abstraction “Lifecycle Management” to enforce that. If it is >> the case, ‘implementers’ of this abstraction really misused concept of >> design. >> One: >> There is no semantic validation. The “Lifecycle Management” >> abstraction has great semantic and just naming ‘init’, ‘destroy’ >> cannot get this as it is just syntax. Abstractions are the ever greats >> things that builds the any system. Currently, there is no >> differentiating on calling a method based on ‘init’ or ‘destroy’ has >> been already called or not on that. Definitely, it can get exceptions >> like ‘NPE’ if ‘init’ had not been called. This is not semantic >> validation but failure due to avoiding it. I can remind some >> situations … As I remind some user has reported errors that have been >> happe
Re: svn commit: r753144 - in /synapse/trunk/java/modules: core/src/main/java/org/apache/synapse/mediators/builtin/ core/src/main/java/org/apache/synapse/mediators/db/ core/src/main/java/org/apache/s
Indika, I still fail to see how the fact that AbstractMediator implements ManagedLifecycle (with empty default implementations for init and destroy) is enforcing anything. What is the improvement compared with the situation before? On the other hand, I agree with you that the issues related to mediator lifecycle management that we have seen in the past are (or at least could be seen as) an indication of a flaw in the design. Indeed, one attribute of a good design or architecture is that it enforces things and prevents people from implementing things in the wrong way. >From the issues we have seen in the past, I would identify two problems with the current lifecycle management: 1. We rely on the fact that mediators having child sequences (list mediators, switch-case, etc.) are able to correctly manage the lifecycle of their child mediators. We have seen examples in the past where this wasn't the case. 2. We will sooner or later run into problems where during initialization, one managed object tries to interact with another managed object that has not yet been initialized. (This is the typical problem that arises with managed objects) If we want to avoid these issues, then we should use (or should have used) another pattern: Register all managed objects in a central place as soon as they are created. Note that in case of mediators, this would require some sort of configuration context to be passed around to MediatorFactory implementations and to MediatorFactoryFinder (getMediator in particular). Instead of initializing the managed objects recursively as described above, one would then simply initialize all the registered objects sequentially. This solves issue 1 and enforces lifecycle management because the only place where a mediator can be created is MediatorFactoryFinder#getMediator and that method would require the configuration context. The pattern could also be used to solve issue 2 because one could postpone the initialization of a managed object if it fails due to some uninitialized dependency. The problem with all this is that it would require some substantial changes that will break existing code... Regards, Andreas On Mon, Mar 16, 2009 at 17:53, indika kumara wrote: > Hi All > > Just now had a time to look at this. > > Actually what I did from commit say by my commit log ‘remove > ManagedLifecycle from mediators that extends AbstractMediator as > AbstractMediator already implements ManagedLifecycle’. Actually, I > just replied to the thread as I have to replay as this related with > me. I just want to get rid if this thread as I had many works to do > and I really don’t care other things, when I have important things to > do. > > I am trying to take design decision on this and I expect to get answer > for these. > > 1) Is ‘ManagedLifecycle’ is a trick to allow mediators and others to > do require work related with initialization and destroy. Currently, I > can see only this as a trick. Trick is still worked. > 2) Otherwise…. Synapse initiators came up with great set of > abstractions such as mediators, endpoints, tasks, registry, etc to > build an ESB using these abstractions. Then, they have thought that > these abstractions should be properly managed. Therefore, came up with > a new abstraction “Lifecycle Management” to enforce that. If it is > the case, ‘implementers’ of this abstraction really misused concept of > design. > One: > There is no semantic validation. The “Lifecycle Management” > abstraction has great semantic and just naming ‘init’, ‘destroy’ > cannot get this as it is just syntax. Abstractions are the ever greats > things that builds the any system. Currently, there is no > differentiating on calling a method based on ‘init’ or ‘destroy’ has > been already called or not on that. Definitely, it can get exceptions > like ‘NPE’ if ‘init’ had not been called. This is not semantic > validation but failure due to avoiding it. I can remind some > situations … As I remind some user has reported errors that have been > happened due to fact Mediators inside switch case, has not been > initiated. Another situation was occurred when using an indirect > endpoint (only for indirect endpoint) within in send mediator. Send > mediator’s init method did not get called and as a reason indirect > endpoint has been not initialized. Still, this kind of things possible > as any user can create custom mediators and there is no semantic > validation on “Lifecycle Management”. Actually, these are transient > failures - until get executed a particular code fragment failures are > hidden. There are the ever bad failures. All these are happened due to > fact there is no semantic validation on. There cannot be an > abstraction without semantic. Without semantic validation, it is just > a class for use to implements some trick. > > Two: > There are no semantic enforcements. All initialized and not > initialized objects can be used together. > > For the case two, I can only do refractor.
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Hi All I am sorry as I just look at this only now. Just putting my concerns. I actually don’t like for setting http code inside fault mediator. 1) Both ‘fault ‘and ‘property’ mediators have well defined abstraction. Things should be done by a ‘property’ mediator, should not be done by a fault mediator for any reason (if not impossible by other way). 2) If this kind of things are needed for some other protocol or due to any other reasons. Do we add those logics into fault mediator? Use of synapse language API is the most important things than adding Java code. For synapse, synapse language API should be the first choice. There are some great extensions that can be used to add additional behaviors. Hessian specific things can not be a main concern. 1) As Andreas suggests , Axis2 module - This should be possible even I cannot validate 2) Other most important thing is synapse has a great extension - Class mediator. You can make a mediator with the logic you want (if XMediator). And then documents, use after fault mediator for this Hessian specific things. Then, ship these useful mediators that can be used with Class mediator configuration. I just only want to add my concerns as it is the way I thinks. I just want to say the way I think about these and I never want to prove ideas of others are bad or mine are good. Thanks Indika - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: svn commit: r753144 - in /synapse/trunk/java/modules: core/src/main/java/org/apache/synapse/mediators/builtin/ core/src/main/java/org/apache/synapse/mediators/db/ core/src/main/java/org/apache/s
Hi All Just now had a time to look at this. Actually what I did from commit say by my commit log ‘remove ManagedLifecycle from mediators that extends AbstractMediator as AbstractMediator already implements ManagedLifecycle’. Actually, I just replied to the thread as I have to replay as this related with me. I just want to get rid if this thread as I had many works to do and I really don’t care other things, when I have important things to do. I am trying to take design decision on this and I expect to get answer for these. 1) Is ‘ManagedLifecycle’ is a trick to allow mediators and others to do require work related with initialization and destroy. Currently, I can see only this as a trick. Trick is still worked. 2) Otherwise…. Synapse initiators came up with great set of abstractions such as mediators, endpoints, tasks, registry, etc to build an ESB using these abstractions. Then, they have thought that these abstractions should be properly managed. Therefore, came up with a new abstraction “Lifecycle Management” to enforce that. If it is the case, ‘implementers’ of this abstraction really misused concept of design. One: There is no semantic validation. The “Lifecycle Management” abstraction has great semantic and just naming ‘init’, ‘destroy’ cannot get this as it is just syntax. Abstractions are the ever greats things that builds the any system. Currently, there is no differentiating on calling a method based on ‘init’ or ‘destroy’ has been already called or not on that. Definitely, it can get exceptions like ‘NPE’ if ‘init’ had not been called. This is not semantic validation but failure due to avoiding it. I can remind some situations … As I remind some user has reported errors that have been happened due to fact Mediators inside switch case, has not been initiated. Another situation was occurred when using an indirect endpoint (only for indirect endpoint) within in send mediator. Send mediator’s init method did not get called and as a reason indirect endpoint has been not initialized. Still, this kind of things possible as any user can create custom mediators and there is no semantic validation on “Lifecycle Management”. Actually, these are transient failures - until get executed a particular code fragment failures are hidden. There are the ever bad failures. All these are happened due to fact there is no semantic validation on. There cannot be an abstraction without semantic. Without semantic validation, it is just a class for use to implements some trick. Two: There are no semantic enforcements. All initialized and not initialized objects can be used together. For the case two, I can only do refractor. I just want to say the way I think about these and never want to prove concerns of others are bad or good. I may have said one to one. If it was happened it is completely due I wanted get grid of this thread as I had many works to do. Thanks Indika - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Updated: (SYNAPSE-519) Cant start synapse using synapse war
[ https://issues.apache.org/jira/browse/SYNAPSE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charith Dhanushka Wickramarachchi updated SYNAPSE-519: -- Attachment: patch.txt patch to resolve the complete issue problems solved 1.there was a bug in the code which try to set the synapse home in the place where server name should 2.synapse war does not contain nessory jars that need to build the ConfigurationContext (eg: axis2 transports ) please review and commit > Cant start synapse using synapse war > > > Key: SYNAPSE-519 > URL: https://issues.apache.org/jira/browse/SYNAPSE-519 > Project: Synapse > Issue Type: Bug > Components: Deployment >Affects Versions: 1.3 > Environment: Ubuntu 8.10 >Reporter: Charith Dhanushka Wickramarachchi >Priority: Blocker > Attachments: patch.txt, patch.txt > > > when trying to start synapse using synapse.war there is a fatal massage > coming synapse home is not set > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Updated: (SYNAPSE-519) Cant start synapse using synapse war
[ https://issues.apache.org/jira/browse/SYNAPSE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charith Dhanushka Wickramarachchi updated SYNAPSE-519: -- Attachment: patch.txt There was a small bug in the code that causes the issue this is the patch to resolve the bug Then i got a another error that occues when SynapseContoller try to build the ConfigurationContext I'm working on that error to resolve this issue > Cant start synapse using synapse war > > > Key: SYNAPSE-519 > URL: https://issues.apache.org/jira/browse/SYNAPSE-519 > Project: Synapse > Issue Type: Bug > Components: Deployment >Affects Versions: 1.3 > Environment: Ubuntu 8.10 >Reporter: Charith Dhanushka Wickramarachchi >Priority: Blocker > Attachments: patch.txt > > > when trying to start synapse using synapse.war there is a fatal massage > coming synapse home is not set > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Created: (SYNAPSE-519) Cant start synapse using synapse war
Cant start synapse using synapse war Key: SYNAPSE-519 URL: https://issues.apache.org/jira/browse/SYNAPSE-519 Project: Synapse Issue Type: Bug Components: Deployment Affects Versions: 1.3 Environment: Ubuntu 8.10 Reporter: Charith Dhanushka Wickramarachchi Priority: Blocker when trying to start synapse using synapse.war there is a fatal massage coming synapse home is not set -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Sounds good. Andreas On Mon, Mar 16, 2009 at 07:52, Hubert, Eric wrote: > Yes, this has been exactly the direction I was looking for. I guess Asankha > made just a typo in the name of the suggested property and wanted to use > FAULTS_AS_HTTP200 as 500 would be the current default. Then the rest of the > sentence setting it to true in the HessianMessageBuilder would still apply. > ;-) > > > > If nobody objects or has better ideas, I’ll go ahead and propose a patch > following Asankha’s suggestion. > > > > Regards, > > Eric > > > > > > > > From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] > Sent: Monday, March 16, 2009 4:27 AM > To: dev@synapse.apache.org > Subject: Re: Creating HessianFaults using > FaultMediator/HessianMessageFormatter > > > > I think all last three suggestions will work nicely to solve this issue, but > I think asankha's solution seems quite handy in this case as well as in most > of the other POX cases (it is a generic solution). > > I think HessianBuilder should set the value to false in the asankha's > suggestion, because hessian messages want them to be to 200 rather than 500. > :-) > > Thanks, > Ruwan > > On Mon, Mar 16, 2009 at 6:59 AM, Asankha C. Perera > wrote: > > Hi all > > Yes, I think the overhead in the FaultMediator is rather low. It already > handles a lot of other application protocol specific stuff. The only thing > which is not nice is that the way to detect the Hessian message is making > assumptions on the transport used (content-type of http transport header as > a decision criteria). But there are obviously other alternatives to > implement the isHessianMessage() method (e.g. letting the builder write an > info about the application protocol used in a defined place within the > message context or even something smarter?). > > Yes, there are limitations regarding message transformations changing the > application protocol, this is true. On the other side this would be a > relatively hard job. Either reimplementing the whole protocol or integrating > a Hessian library (many library versions are incompatible amongst each > other). Once we really do this, the effort to change a few lines in the > FaultMediator can be neglected. > > Considering all that has been brought up in this thread and the above in > particular, what if we define a new Synapse property say 'FAULTS_AS_HTTP500' > - and the Hessian builders would set this property to True. This way the > fault mediator is not Hessian specific. > > When the fault mediator is invoked later, it would check this property and > perform the logic given in Eric's patch. I believe many POX messages would > also benefit from this - where many fault messages would actually go on the > wire as HTTP 200's.. > > cheers > asankha > > -- > > Asankha C. Perera > > AdroitLogic, http://adroitlogic.org > > > > http://esbmagic.blogspot.com > > > > > > > > > -- > Ruwan Linton > Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb > WSO2 Inc.; http://wso2.org > email: ru...@wso2.com; cell: +94 77 341 3097 > blog: http://ruwansblog.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
+1 Thanks, Rwuan On Mon, Mar 16, 2009 at 12:22 PM, Hubert, Eric wrote: > Yes, this has been exactly the direction I was looking for. I guess > Asankha made just a typo in the name of the suggested property and wanted to > use FAULTS_AS_HTTP200 as 500 would be the current default. Then the rest of > the sentence setting it to true in the HessianMessageBuilder would still > apply. ;-) > > > > If nobody objects or has better ideas, I’ll go ahead and propose a patch > following Asankha’s suggestion. > > > > Regards, > > Eric > > > > > -- > > *From:* Ruwan Linton [mailto:ruwan.lin...@gmail.com] > *Sent:* Monday, March 16, 2009 4:27 AM > *To:* dev@synapse.apache.org > *Subject:* Re: Creating HessianFaults using > FaultMediator/HessianMessageFormatter > > > > I think all last three suggestions will work nicely to solve this issue, > but I think asankha's solution seems quite handy in this case as well as in > most of the other POX cases (it is a generic solution). > > > I think HessianBuilder should set the value to false in the asankha's > suggestion, because hessian messages want them to be to 200 rather than 500. > :-) > > Thanks, > Ruwan > > On Mon, Mar 16, 2009 at 6:59 AM, Asankha C. Perera > wrote: > > Hi all > > Yes, I think the overhead in the FaultMediator is rather low. It already > handles a lot of other application protocol specific stuff. The only thing > which is not nice is that the way to detect the Hessian message is making > assumptions on the transport used (content-type of http transport header as > a decision criteria). But there are obviously other alternatives to > implement the isHessianMessage() method (e.g. letting the builder write an > info about the application protocol used in a defined place within the > message context or even something smarter?). > > Yes, there are limitations regarding message transformations changing the > application protocol, this is true. On the other side this would be a > relatively hard job. Either reimplementing the whole protocol or integrating > a Hessian library (many library versions are incompatible amongst each > other). Once we really do this, the effort to change a few lines in the > FaultMediator can be neglected. > > Considering all that has been brought up in this thread and the above in > particular, what if we define a new Synapse property say 'FAULTS_AS_HTTP500' > - and the Hessian builders would set this property to True. This way the > fault mediator is not Hessian specific. > > When the fault mediator is invoked later, it would check this property and > perform the logic given in Eric's patch. I believe many POX messages would > also benefit from this - where many fault messages would actually go on the > wire as HTTP 200's.. > > cheers > asankha > > -- > > Asankha C. Perera > > AdroitLogic, http://adroitlogic.org > > > > http://esbmagic.blogspot.com > > > > > > > > > > > -- > Ruwan Linton > Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb > WSO2 Inc.; http://wso2.org > email: ru...@wso2.com; cell: +94 77 341 3097 > blog: http://ruwansblog.blogspot.com > -- Ruwan Linton Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
RE: Offer to support Synapse development
Hi, I don't know too much about the corresponding Maven2 plugins and in which phase of the lifecycle they normally operate, but I have a very knowledgeable colleague who also did our Hudson setup. So I can easily get all the needed information. I agree that it does not make sense to run those reports with every build. It takes time and consumes resources. In Hudson we do have a special documentation job accompanying each build job which by default runs only once a day. From my perspective this is totally sufficient to collect quality metrics and let tools check for bad practice and bug patterns. The integration in Hudson is therefore useful, as it offers a very convenient way to obtain those reports and also important check the trend conveniently. The tricky part is the selection/configuration of rules/rulesets to apply. My suggestion: start with a rather small set and increase it incrementally. The same configuration as used in CI should be used inside the IDE with the respective plugins. Most favourite IDEs have nowadays rather sufficient support for those tools. Regards, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Sunday, March 15, 2009 10:33 PM To: dev@synapse.apache.org Subject: Re: Offer to support Synapse development I too agree with Eric here, though they seem to be doing the same thing, each of these have it's own focuses and I would like to see all three reports. Thanks Eric for the nice explanation. So, how are we planning to execute this? Are we going to use the respective maven plugins, if so I would suggest using a different profile for these reports without affecting the normal build flow. AFAIK, these reports are generated at the reporting phase of the maven execution, but of course FindBugs and PMD comes at the compile phase to collect the information to be presented in the report. Thanks, Ruwan On Mon, Mar 16, 2009 at 2:31 AM, Hubert, Eric wrote: > Cool! > > Now, probably it doesn't make sense to use both PMD and findbugs, > especially if we use annotations to suppress specific warnings. Do you > have an idea which one is better? >From my personal experiences this is not true. It makes sense to use both of them in parallel, because although there is in fact some overlapping, they have strength and weaknesses in different areas. It is possible to configure them in a way to reduce the overlapping (not suppressing rules in code, but exclude some rules from the applied ruleset of each tool). Overall PMD is a bit more useful in CI where Findbugs can also help if executed on demand. Findbugs detects bugs, which PMD can't (bytecode versus source code analysis). Number of false positives is higher for Findbugs. A while back a colleague prepared a presentation. One picture was quite useful to demonstrate the different focus of those tools. I attached it to the mail. Hope it comes through... Actually we ended up integrating Checkstyle, PMD and Findbugs in CI. Additionally to the picture here some of my experiences regarding the strength/weaknesses of the tools: Checkstyle -- Focus: CONVENTIONS Naming, code format, consistence code/JavaDoc, design suggestions Pro: + good for big, distributed teams to achieve style consistency + some design metrics are pretty useful to improve the code (decrease complexity) Contra: - configuration always necessary - if used in conjunction with code formatter, rules need to be adjusted to avoid conflicts - if a project has been setup without checkstyle right from the beginning, IDE integration can be painful due to too many violations "for peanuts" (whitespace problems, tab instead of space etc.); rules should then be applied stepwise PMD --- Focus: AVOID BAD PRACTICES Identifies useless control flow, find missing freeing of resources, suggestions for performance improvements, identifies redundant checks etc. Pro: + very good explanation of each violation (including reasoning and hints to do it better + grouping of rules to rulesets + highly customizable (rules in editable xml) + extendable (Java/XML knowledge needed) Contra: - depending on the ruleset, PMD can also output a great number of warnings Findbugs Focus: FIND POTENTIAL BUGS Pro: + identifies real bugs (NPE, Death Store, multithreading problems due to wrong synchronization) Contra: - number of false positives (problems with compile optimizations, dependency injection etc.) Very interesting is also what's going on in the sonar open source project: http://sonar.codehaus.org/ Here you can find something in action: http://nemo.sonar.codehaus.org/ They also think that all the above tools are valuable and try to integrate their results. They have also a Hudson plugin available, but I did not find time to investigate: http://sonar.codehaus.org/a-new-hudson-plugin-for-a-closer-integration-w ith-sonar/ Regards, Eric - To unsubscribe
