John Graham wrote:
> How to change the order of classpaths ? Press F1 :)
>
You might laugh, but in a previous life I dealt with a product team that
was convinced users are not going to know about F1, and thus wanted big
"Help" buttons added all over the product. ;)
> With respect to more specifically in ESB then sure, find a good spot
> in the ESB docs and add it in.
>
Yes, specifically about the jars we know are impacted: scout and juddi.
Denny: Can you coordinate getting this information added to the JBDS ESB
documentation?
OK, I will add the information to the JBDS documentation.
Denny
-- John
On Thu, 2009-02-19 at 16:48 +0100, Max Rydahl Andersen wrote:
> On 19-02-2009 16:47, John Graham wrote:
>
>>> That is something the user can fix then.
>>>
>>>
>> Can we document this somewhere in the product?
>>
>>
> How to change the order of classpaths ? Press F1 :)
>
> With respect to more specifically in ESB then sure, find a good spot
> in the ESB docs and add it in.
>
> /max
>
>> -- John
>>
>> On Thu, 2009-02-19 at 16:42 +0100, Max Rydahl Andersen wrote:
>>
>>
>>> On 19-02-2009 07:54, Denny Xu wrote:
>>>
>>>
>>>> John and Max, today ESB cp container has been being in front of AS cp
>>>> container on ESB project classpath, after you
>>>> create a esb project, you can look at the .classpath file, the default
>>>> order is that the ESB cp container is in front of AS cp.
>>>>
>>>>
>>>>
>>> okey, sounds good...so what was the cause of the original error ?
>>> Does it just work outside the box ?
>>>
>>>
>>>> There might be a problem for a ESB client project, users might create
>>>> a Java project as ESB client project and then
>>>> add ESB and AS library to the project with wrong order manually, so
>>>> the wrong scout.jar would be loaded.
>>>>
>>>>
>>> That is something the user can fix then.
>>> We can help by creating a "ESB client project" wizard (or facet?)
>>>
>>> /max
>>>
>>>
>>>> Denny
>>>>
>>>> John Graham wrote:
>>>>
>>>>
>>>>> Denny,
>>>>>
>>>>> Max and I discussed this, and for the time being (this release),
we'd
>>>>> just like to move the ESB cp container ahead of the AS cp container
on
>>>>> the project classpath. This will allow override libs in the ESB
>>>>> classpath container to be loaded first.
>>>>> Is this possible, and, if so, can you take care of this?
>>>>>
>>>>> -- John
>>>>>
>>>>> On Wed, 2009-02-18 at 21:56 +0800, Denny Xu wrote:
>>>>>
>>>>>
>>>>>> Max Rydahl Andersen wrote:
>>>>>>
>>>>>>
>>>>>>>>>> set up a development environment by
>>>>>>>>>> a standalone ESB runtime and there is not a ESB
specified
>>>>>>>>>> classpath container, how could he do?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Eh - how do you do if there is not an ESB in the
runtime ? You
>>>>>>>>> would be in the same situation, right ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> For current ESB project, there are two separate
functions, the
>>>>>>>> first one
>>>>>>>> is setting ESB runtime classpath for the project, and
another is
>>>>>>>> deployment. two functions have dependency on project
target server
>>>>>>>> runtime, but the two dependencies are different, Setting
esb runtime
>>>>>>>> classpath is just ensure that the project can
>>>>>>>> compile against ESB. if the project target runtime does
not contain
>>>>>>>> an ESB runtime, users can provide a predefined JBoss ESB
runtime,
>>>>>>>> so users can write esb code at least, but if ESB project
tight
>>>>>>>> couple with project target runtime server, users can do
nothing
>>>>>>>> without setting target runtime correctly.
>>>>>>>>
>>>>>>>>
>>>>>>> I do not see how this requires a different ESB classpath
container
>>>>>>> and especially since you would really
>>>>>>> like to make sure that users compile against the same thing
they
>>>>>>> deploy against.
>>>>>>>
>>>>>>>
>>>>>> Yes, a reasonable logic should be that, but users might deploy
the
>>>>>> project to any server which runtime
>>>>>> supports the project facet, as far as I know, wtp deployment does
>>>>>> not have limitation that the project only can be deployed
>>>>>> to the project's target server, that means the project
target
>>>>>> server runtime has nothing to do with the deployment,
>>>>>> so it maybe hard to ensure that users compile against the same
>>>>>> thing they deploy against.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> In what situations today is an ESB project useful without
having a
>>>>>>> targeted runtime ?
>>>>>>>
>>>>>>>
>>>>>> Users can select a predefined standalone ESB runtime, so they can
>>>>>> program and then deploy,
>>>>>> not sure if it's the best logic, maybe ask the server
runtime pick
>>>>>> up jars is a good solution.
>>>>>>
>>>>>> Denny
>>>>>>
>>>>>>
>>
>>