[jbosstools-dev] classpath containers

[Max Rydahl Andersen]

On 23-02-2009 11:48, Rob Stryker wrote:
> 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)
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
>
> 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 at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>