Just saw https://jira.jboss.org/jira/browse/JBIDE-3836 which shows how bad it is that we now have the classpath containers duplicated. That issue I see as being just as relevant for WS, AS and ESB....not something that should just be fixed in the ESB classpath container. Could we please move the base set of functionality (source/java doc attachement and basic CPC func) back into AS core and all base on that at least for GA ? /max _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

On 20-02-2009 20:55, Snjezana Peco wrote: > I have seen the changes related to JBIDE-3836 and think they will > break performance. okey looking at it I agree. Even more important we don't start forking of different classpath container behavior. Why is that fix necessary to always calculate it instead of just caching it ? afaik other classpath containers just gets refreshed forcefully when something related to changes instead of on every calculation. Could we get these things aligned before GA ? /max > Namely, IClasspathContainer.getClasspathEntries() is often called > which is the reason entries are cached within a classpath container. > This isn't specific for our containers. Almost all of Eclipse/WTP > containers work this way. > > Denny, > > Could you tell us the steps to reproduce the issue mentioned in > JBIDE-3836? > > Snjeza > > Max Rydahl Andersen wrote: >> Just saw https://jira.jboss.org/jira/browse/JBIDE-3836 which shows >> how bad it is that we now have the classpath containers duplicated. >> >> That issue I see as being just as relevant for WS, AS and ESB....not >> something that should just be fixed in the ESB classpath container. >> >> Could we please move the base set of functionality (source/java doc >> attachement and basic CPC func) back into AS core and all base >> on that at least for GA ? >> >> /max >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >

> I suppose that Denny faced the issue similar to the issue described > in https://jira.jboss.org/jira/browse/JBIDE-3733 . > A classpath container can't be updated using > JavaCore.setClasspathContainer(...). The > AbstractClasspathContainer.refresh() method must be used. > This method creates a new classpath container and informs JDT that > the classpath container has been changed. so if it was fixed then I wonder why it is an issue now ? Or is it a different issue ?

Anyhow - lets gets this stuff unified into where it was before so these fixes doesn't have to be copied around. /max > > Snjeza > > Max Rydahl Andersen wrote: >> On 20-02-2009 20:55, Snjezana Peco wrote: >>> I have seen the changes related to JBIDE-3836 and think they will >>> break performance. >> okey looking at it I agree. >> >> Even more important we don't start forking of different classpath >> container behavior. >> >> Why is that fix necessary to always calculate it instead of just >> caching it ? >> afaik other classpath containers just gets refreshed forcefully when >> something related to changes instead of on every calculation. >> >> Could we get these things aligned before GA ? >> >> /max >>> Namely, IClasspathContainer.getClasspathEntries() is often called >>> which is the reason entries are cached within a classpath container. >>> This isn't specific for our containers. Almost all of Eclipse/WTP >>> containers work this way. >>> >>> Denny, >>> >>> Could you tell us the steps to reproduce the issue mentioned in >>> JBIDE-3836? >>> >>> Snjeza >>> >>> Max Rydahl Andersen wrote: >>>> Just saw https://jira.jboss.org/jira/browse/JBIDE-3836 which shows >>>> how bad it is that we now have the classpath containers duplicated. >>>> >>>> That issue I see as being just as relevant for WS, AS and >>>> ESB....not something that should just be fixed in the ESB >>>> classpath container. >>>> >>>> Could we please move the base set of functionality (source/java >>>> doc attachement and basic CPC func) back into AS core and all base >>>> on that at least for GA ? >>>> >>>> /max >>>> _______________________________________________ >>>> jbosstools-dev mailing list >>>> jbosstools-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>> >> >

> As soon as Denny provides us with the steps to reproduce this issue, > I will check it. To reproduce the issue in ESB classpath container: 1. In workspace "workspace1", Create a ESB project by ESB project wizard with server supplied ESB runtime, and then there will be two classpath contianer, one is jboss as server runtime cp, and another is ESB runtiem cp. 2. Import the project into the workspace "workspace2", workspace2 does not have the server runtime that specified in workspace1, at the moment , the two classpath containers can not display the jars of the runtimes since the workspace2 doesn't has the server runtime. 3. Create a server runtime with the name is the same as specified in the project in workspace2 , then the AS runtime CP can display all jars but ESB runtime CP can't .

Denny > > Snjeza > >> Anyhow - lets gets this stuff unified into where it was before so >> these fixes doesn't have to be copied around. >> >> /max >>> >>> Snjeza >>> >>> Max Rydahl Andersen wrote: >>>> On 20-02-2009 20:55, Snjezana Peco wrote: >>>>> I have seen the changes related to JBIDE-3836 and think they will >>>>> break performance. >>>> okey looking at it I agree. >>>> >>>> Even more important we don't start forking of different classpath >>>> container behavior. >>>> >>>> Why is that fix necessary to always calculate it instead of just >>>> caching it ? >>>> afaik other classpath containers just gets refreshed forcefully >>>> when something related to changes instead of on every calculation. >>>> >>>> Could we get these things aligned before GA ? >>>> >>>> /max >>>>> Namely, IClasspathContainer.getClasspathEntries() is often called >>>>> which is the reason entries are cached within a classpath container. >>>>> This isn't specific for our containers. Almost all of Eclipse/WTP >>>>> containers work this way. >>>>> >>>>> Denny, >>>>> >>>>> Could you tell us the steps to reproduce the issue mentioned in >>>>> JBIDE-3836? >>>>> >>>>> Snjeza >>>>> >>>>> Max Rydahl Andersen wrote: >>>>>> Just saw https://jira.jboss.org/jira/browse/JBIDE-3836 which >>>>>> shows how bad it is that we now have the classpath containers >>>>>> duplicated. >>>>>> >>>>>> That issue I see as being just as relevant for WS, AS and >>>>>> ESB....not something that should just be fixed in the ESB >>>>>> classpath container. >>>>>> >>>>>> Could we please move the base set of functionality (source/java >>>>>> doc attachement and basic CPC func) back into AS core and all base >>>>>> on that at least for GA ? >>>>>> >>>>>> /max >>>>>> _______________________________________________ >>>>>> jbosstools-dev mailing list >>>>>> jbosstools-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>>> >>>> >>> >> >

Basically Denny should be listening for server runtime changes (deletions / renames etc) and then refreshing his container manually. He needs to listen to what he decides is relevant and refresh accordingly. This is, again, an issue of mis-using a classpath container or not understanding how to use it before doing so. It is not a coding issue or a bug in the classpath container (superclass at least)

Max Rydahl Andersen wrote: > >>> As soon as Denny provides us with the steps to reproduce this >>> issue, I will check it. >> To reproduce the issue in ESB classpath container: >> 1. In workspace "workspace1", Create a ESB project by ESB project >> wizard with server supplied ESB runtime, >> and then there will be two classpath contianer, one is jboss as >> server runtime cp, and another is ESB runtiem cp. >> 2. Import the project into the workspace "workspace2", workspace2 >> does not have the server runtime that specified >> in workspace1, at the moment , the two classpath containers can not >> display the jars of the runtimes since the workspace2 >> doesn't has the server runtime. >> 3. Create a server runtime with the name is the same as specified in >> the project in workspace2 , then the AS runtime CP >> can display all jars but ESB runtime CP can't . > Thanks Denny, and thanks for adding it to jira too. > > fyi, adding such steps to reproduce an issue is also necessary to get > QA to verify the issues so its important to do that > for any non-trivial issue. > > I've reopened the issue and Snjezana will look into getting this > fixed (hopefully without too much code duplication ,) > > -max >> >> Denny >> >>> >>> Snjeza >>> >>>> Anyhow - lets gets this stuff unified into where it was before so >>>> these fixes doesn't have to be copied around. >>>> >>>> /max >>>>> >>>>> Snjeza >>>>> >>>>> Max Rydahl Andersen wrote: >>>>>> On 20-02-2009 20:55, Snjezana Peco wrote: >>>>>>> I have seen the changes related to JBIDE-3836 and think they >>>>>>> will break performance. >>>>>> okey looking at it I agree. >>>>>> >>>>>> Even more important we don't start forking of different >>>>>> classpath container behavior. >>>>>> >>>>>> Why is that fix necessary to always calculate it instead of just >>>>>> caching it ? >>>>>> afaik other classpath containers just gets refreshed forcefully >>>>>> when something related to changes instead of on every calculation. >>>>>> >>>>>> Could we get these things aligned before GA ? >>>>>> >>>>>> /max >>>>>>> Namely, IClasspathContainer.getClasspathEntries() is often >>>>>>> called which is the reason entries are cached within a >>>>>>> classpath container. >>>>>>> This isn't specific for our containers. Almost all of >>>>>>> Eclipse/WTP containers work this way. >>>>>>> >>>>>>> Denny, >>>>>>> >>>>>>> Could you tell us the steps to reproduce the issue mentioned in >>>>>>> JBIDE-3836? >>>>>>> >>>>>>> Snjeza >>>>>>> >>>>>>> Max Rydahl Andersen wrote: >>>>>>>> Just saw https://jira.jboss.org/jira/browse/JBIDE-3836 which >>>>>>>> shows how bad it is that we now have the classpath containers >>>>>>>> duplicated. >>>>>>>> >>>>>>>> That issue I see as being just as relevant for WS, AS and >>>>>>>> ESB....not something that should just be fixed in the ESB >>>>>>>> classpath container. >>>>>>>> >>>>>>>> Could we please move the base set of functionality >>>>>>>> (source/java doc attachement and basic CPC func) back into AS >>>>>>>> core and all base >>>>>>>> on that at least for GA ? >>>>>>>> >>>>>>>> /max >>>>>>>> _______________________________________________ >>>>>>>> jbosstools-dev mailing list >>>>>>>> jbosstools-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>>>>> >>>>>> >>>>> >>>> >>> >> > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Max Rydahl Andersen wrote: > Great, so only do the fix in the ESB specific code and if possible > refactor it up in the base instead of changing a copied base.. > > Anyway, the current fix is not performant. > > /max There is no code to refactor or contribute up to the base. Zero. He doesn't need to change hte copied base at all. He just needs to install a listener on the server / runtime models to find out when a runtime disappears and manually call refresh on his CPC. He'd have to do this whether it was an as.core base or a copied base or anything. The container has a "refresh" method which never gets called on its own. The user must call it himself. This behavior is not done automatically for you. So no changes must be made to his CPC, neither the copied abstract base nor the subclass. Which means nothing must be contributed up to as.classpath

Max Rydahl Andersen wrote: > Great, so only do the fix in the ESB specific code and if possible > refactor it up in the base instead of changing a copied base.. > > Anyway, the current fix is not performant. > > /max There is no code to refactor or contribute up to the base. Zero. He doesn't need to change hte copied base at all. He just needs to install a listener on the server / runtime models to find out when a runtime disappears and manually call refresh on his CPC. He'd have to do this whether it was an as.core base or a copied base or anything. The container has a "refresh" method which never gets called on its own. The user must call it himself. This behavior is not done automatically for you. So no changes must be made to his CPC, neither the copied abstract base nor the subclass. Which means nothing must be contributed up to as.classpath