[jbosstools-dev] Re: [Soa-tools-list] Example of why consistent jar usage is important

[John Graham]

> That is something the user can fix then.

Can we document this somewhere in the product?

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