<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
On 19-02-2009 16:47, John Graham wrote:
<blockquote cite="mid:1235058477.3317.12.camel@localhost.localdomain"
type="cite">
<blockquote type="cite">
<pre wrap="">That is something the user can fix then.
</pre>
</blockquote>
<pre wrap=""><!---->
Can we document this somewhere in the product?
</pre>
</blockquote>
How to change the order of classpaths ? Press F1 :)<br>
<br>
With respect to more specifically in ESB then sure, find a good spot in
the ESB docs and add it in.<br>
<br>
/max<br>
<blockquote cite="mid:1235058477.3317.12.camel@localhost.localdomain"
type="cite">
<pre wrap="">
-- John
On Thu, 2009-02-19 at 16:42 +0100, Max Rydahl Andersen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 19-02-2009 07:54, Denny Xu wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">okey, sounds good...so what was the cause of the original error ?
Does it just work outside the box ?
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">That is something the user can fix then.
We can help by creating a "ESB client project" wizard (or facet?)
/max
</pre>
<blockquote type="cite">
<pre wrap="">Denny
John Graham wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">Max Rydahl Andersen wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">set up a development environment by
a standalone ESB runtime and there is not a ESB specified
classpath container, how could he do?
</pre>
</blockquote>
<pre wrap="">Eh - how do you do if there is not an ESB in the runtime ? You
would be in the same situation, right ?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">In what situations today is an ESB project useful without having a
targeted runtime ?
</pre>
</blockquote>
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>