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
>>>>