11:12 a.m.
>
> The short term solution is to drop the ESB specific classpath
> container IMO.
> And let the AS classpath container calculate which jars to return
> dependent on which facets are installed.
>
> That will allow for dynamic calculation - I don't really understand
> why it wasn't done like this in the beginning.
> Denny / Rob can you let us know ?
ESB project has two main functions
one is creating a ESB project for developing ESB by set up classpath
and another is deploying ESB project,
ESB register itself to AS runtime, is just for deploying project using
WTP deployment way.
Let me explain why there is a ESB specified classpath container:
Firstly, AS server runtime can not ensure that it can provide a proper
ESB runtime any time,
because not all JBoss Servers contain ESB runtime, if a user just want
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 ?
Currently, there are two options for creating ESB classpath container,
1. get ESB runtime jars from specified AS runtime
2. get jars from a specified ESB runtime which predefined in
preference page.
for now, AS classpath container is used as non-facet related
classpath, I don't think it can pick up jars
for all project facet, there maybe JBossWS facet, it need JBossWS
runtime, JBoss ESB facet need
ESB runtime, and Seam facet Seam runtime, AS classpath container
almost don't know where the
location and structure of an new added runtime.
Seam facet is not doable because
Seam jar's are not part of the AS
runtime (it is "outside" and needs deploying inside the app),
ESB and WS are all "inside" the AS runtime and AS could calculate these.
btw. I think all of this is more for jbosstools-dev than SOA tools since
it is not soa specific.
If AS classpath container can provide a extension point for new facet
and runtime, every new facet
just need extend the extension point by providing a jars calculation
logic and AS runtime pick jars
from extensions. that would be good.
Yes - maybe runtime components can do this
?
/max
Denny
>
> Nor do I understand how users is supposed to know which jars' to
> compile/run against with the current platform
> setup we have ;)
>
> /max
>> I've been looking into this during the morning, and so far here is what
>> I've got:
>>
>> This appears to be a case of SOA-P using an AS capability that the
>> tooling has no easy way to accommodate at present. That is, SOA-P is
>> able to override certain libraries contained in AS by default for its
>> own use, and thus applications written for SOA-P (as opposed to just
>> AS)
>> need to be configured accordingly. Now, we might wish that the world is
>> flat, but reality intrudes with much more complex demands. The simple
>> fact that there are library/classloader scope capabilities in AS that
>> are not readily supported by the current tools means that other more
>> complex enterprise applications could run into similar issues.
>> A potential solution (though not in this release of tools) is to
>> provide
>> a Eclipse launch configuration that allows for classpath container
>> manipulation and perhaps makes some educated guesses ("if ESB and
>> duplicate jar between ESB and AS, remove AS jar from classpath" for
>> example) in the default settings. This would enable users to handle a
>> host of classpath configuration details when developing with AS, not
>> just for ESB.
>>
>> For the short term (this release), I think the only viable option is to
>> identify the known overlap and work-around it as best as possible. This
>> might include dropping known problematic jars from the classpath or
>> simply user documentation.
>>
>> -- John
>>
>> On Fri, 2009-02-13 at 15:22 +0000, Mark Little wrote:
>>> Hi Max. I'm not sure why this email is blank (at least I can't use
>>> it). Anyway, I've asked John to take a look at the problem from our
>>> side since I'm on vacation next week. I think we all know what we want
>>> to be able to do with tooling, so let's identify the issues and get
>>> them fixed. I don't believe this is an insurmountable issue.
>>>
>>>
>>> Mark.
>>>
>>>
>>>
>>> On 13 Feb 2009, at 14:46, Max Rydahl Andersen wrote:
>>>
>>>>
>>> ----
>>>
>>>
>>> Mark Little
>>> mlittle(a)redhat.com
>>>
>>>
>>> JBoss, a Division of Red Hat
>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
>>> Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in
>>> UK and Wales under Company Registration No. 3798903 Directors:
>>> Michael Cunningham (USA), Charlie Peters (USA), Matt
>>> Parsons (USA) and Brendan Lane (Ireland)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Soa-tools-list mailing list
>>> Soa-tools-list(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/soa-tools-list
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Soa-tools-list mailing list
> Soa-tools-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/soa-tools-list
9:46 a.m.
New subject: [Soa-tools-list] Example of why consistent jar usage is important
On Tue, 2009-02-17 at 11:12 +0100, Max Rydahl Andersen wrote:
>>
>> The short term solution is to drop the ESB specific classpath
>> container IMO.
>> And let the AS classpath container calculate which jars to return
>> dependent on which facets are installed.
>>
>> That will allow for dynamic calculation - I don't really understand
>> why it wasn't done like this in the beginning.
>> Denny / Rob can you let us know ?
> ESB project has two main functions
> one is creating a ESB project for developing ESB by set up classpath
> and another is deploying ESB project,
> ESB register itself to AS runtime, is just for deploying project using
> WTP deployment way.
>
> Let me explain why there is a ESB specified classpath container:
> Firstly, AS server runtime can not ensure that it can provide a proper
> ESB runtime any time,
> because not all JBoss Servers contain ESB runtime, if a user just want
> 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.
Denny
>
> Currently, there are two options for creating ESB classpath container,
> 1. get ESB runtime jars from specified AS runtime
> 2. get jars from a specified ESB runtime which predefined in
> preference page.
> for now, AS classpath container is used as non-facet related
> classpath, I don't think it can pick up jars
> for all project facet, there maybe JBossWS facet, it need JBossWS
> runtime, JBoss ESB facet need
> ESB runtime, and Seam facet Seam runtime, AS classpath container
> almost don't know where the
> location and structure of an new added runtime.
Seam facet is not doable because Seam jar's are not part of the AS
runtime (it is "outside" and needs deploying inside the app),
ESB and WS are all "inside" the AS runtime and AS could calculate these.
btw. I think all of this is more for jbosstools-dev than SOA tools since
it is not soa specific.
> If AS classpath container can provide a extension point for new facet
> and runtime, every new facet
> just need extend the extension point by providing a jars calculation
> logic and AS runtime pick jars
> from extensions. that would be good.
Yes - maybe runtime components can do this ?
/max
>
> Denny
>
>
>>
>> Nor do I understand how users is supposed to know which jars' to
>> compile/run against with the current platform
>> setup we have ;)
>>
>> /max
>>> I've been looking into this during the morning, and so far here is what
>>> I've got:
>>>
>>> This appears to be a case of SOA-P using an AS capability that the
>>> tooling has no easy way to accommodate at present. That is, SOA-P is
>>> able to override certain libraries contained in AS by default for its
>>> own use, and thus applications written for SOA-P (as opposed to just
>>> AS)
>>> need to be configured accordingly. Now, we might wish that the world is
>>> flat, but reality intrudes with much more complex demands. The simple
>>> fact that there are library/classloader scope capabilities in AS that
>>> are not readily supported by the current tools means that other more
>>> complex enterprise applications could run into similar issues.
>>> A potential solution (though not in this release of tools) is to
>>> provide
>>> a Eclipse launch configuration that allows for classpath container
>>> manipulation and perhaps makes some educated guesses ("if ESB and
>>> duplicate jar between ESB and AS, remove AS jar from classpath" for
>>> example) in the default settings. This would enable users to handle a
>>> host of classpath configuration details when developing with AS, not
>>> just for ESB.
>>>
>>> For the short term (this release), I think the only viable option is to
>>> identify the known overlap and work-around it as best as possible. This
>>> might include dropping known problematic jars from the classpath or
>>> simply user documentation.
>>>
>>> -- John
>>>
>>> On Fri, 2009-02-13 at 15:22 +0000, Mark Little wrote:
>>>> Hi Max. I'm not sure why this email is blank (at least I can't
use
>>>> it). Anyway, I've asked John to take a look at the problem from our
>>>> side since I'm on vacation next week. I think we all know what we
want
>>>> to be able to do with tooling, so let's identify the issues and get
>>>> them fixed. I don't believe this is an insurmountable issue.
>>>>
>>>>
>>>> Mark.
>>>>
>>>>
>>>>
>>>> On 13 Feb 2009, at 14:46, Max Rydahl Andersen wrote:
>>>>
>>>>>
>>>> ----
>>>>
>>>>
>>>> Mark Little
>>>> mlittle(a)redhat.com
>>>>
>>>>
>>>> JBoss, a Division of Red Hat
>>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
>>>> Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in
>>>> UK and Wales under Company Registration No. 3798903 Directors:
>>>> Michael Cunningham (USA), Charlie Peters (USA), Matt
>>>> Parsons (USA) and Brendan Lane (Ireland)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Soa-tools-list mailing list
>>>> Soa-tools-list(a)redhat.com
>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list
>>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Soa-tools-list mailing list
>> Soa-tools-list(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/soa-tools-list
>
10:37 a.m.
New subject: [Soa-tools-list] Example of why consistent jar usage is important
>> 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.
In what situations today is an ESB project useful without having a
targeted runtime ?
/max
Denny
>> Currently, there are two options for creating ESB classpath container,
>> 1. get ESB runtime jars from specified AS runtime
>> 2. get jars from a specified ESB runtime which predefined in
>> preference page.
>> for now, AS classpath container is used as non-facet related
>> classpath, I don't think it can pick up jars
>> for all project facet, there maybe JBossWS facet, it need JBossWS
>> runtime, JBoss ESB facet need
>> ESB runtime, and Seam facet Seam runtime, AS classpath container
>> almost don't know where the
>> location and structure of an new added runtime.
>>
> Seam facet is not doable because Seam jar's are not part of the AS
> runtime (it is "outside" and needs deploying inside the app),
> ESB and WS are all "inside" the AS runtime and AS could calculate these.
>
> btw. I think all of this is more for jbosstools-dev than SOA tools since
> it is not soa specific.
>
>> If AS classpath container can provide a extension point for new facet
>> and runtime, every new facet
>> just need extend the extension point by providing a jars calculation
>> logic and AS runtime pick jars
>> from extensions. that would be good.
>>
> Yes - maybe runtime components can do this ?
>
> /max
>
>> Denny
>>
>>
>>
>>> Nor do I understand how users is supposed to know which jars' to
>>> compile/run against with the current platform
>>> setup we have ;)
>>>
>>> /max
>>>
>>>> I've been looking into this during the morning, and so far here is
what
>>>> I've got:
>>>>
>>>> This appears to be a case of SOA-P using an AS capability that the
>>>> tooling has no easy way to accommodate at present. That is, SOA-P is
>>>> able to override certain libraries contained in AS by default for its
>>>> own use, and thus applications written for SOA-P (as opposed to just
>>>> AS)
>>>> need to be configured accordingly. Now, we might wish that the world is
>>>> flat, but reality intrudes with much more complex demands. The simple
>>>> fact that there are library/classloader scope capabilities in AS that
>>>> are not readily supported by the current tools means that other more
>>>> complex enterprise applications could run into similar issues.
>>>> A potential solution (though not in this release of tools) is to
>>>> provide
>>>> a Eclipse launch configuration that allows for classpath container
>>>> manipulation and perhaps makes some educated guesses ("if ESB and
>>>> duplicate jar between ESB and AS, remove AS jar from classpath" for
>>>> example) in the default settings. This would enable users to handle a
>>>> host of classpath configuration details when developing with AS, not
>>>> just for ESB.
>>>>
>>>> For the short term (this release), I think the only viable option is to
>>>> identify the known overlap and work-around it as best as possible. This
>>>> might include dropping known problematic jars from the classpath or
>>>> simply user documentation.
>>>>
>>>> -- John
>>>>
>>>> On Fri, 2009-02-13 at 15:22 +0000, Mark Little wrote:
>>>>
>>>>> Hi Max. I'm not sure why this email is blank (at least I
can't use
>>>>> it). Anyway, I've asked John to take a look at the problem from
our
>>>>> side since I'm on vacation next week. I think we all know what we
want
>>>>> to be able to do with tooling, so let's identify the issues and
get
>>>>> them fixed. I don't believe this is an insurmountable issue.
>>>>>
>>>>>
>>>>> Mark.
>>>>>
>>>>>
>>>>>
>>>>> On 13 Feb 2009, at 14:46, Max Rydahl Andersen wrote:
>>>>>
>>>>>
>>>>> ----
>>>>>
>>>>>
>>>>> Mark Little
>>>>> mlittle(a)redhat.com
>>>>>
>>>>>
>>>>> JBoss, a Division of Red Hat
>>>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
>>>>> Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in
>>>>> UK and Wales under Company Registration No. 3798903 Directors:
>>>>> Michael Cunningham (USA), Charlie Peters (USA), Matt
>>>>> Parsons (USA) and Brendan Lane (Ireland)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Soa-tools-list mailing list
>>>>> Soa-tools-list(a)redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/soa-tools-list
>>>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Soa-tools-list mailing list
>>> Soa-tools-list(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/soa-tools-list
>>>
2:56 p.m.
New subject: [Soa-tools-list] Example of why consistent jar usage is important
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
4:39 p.m.
New subject: [Soa-tools-list] Example of why consistent jar usage is important
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
7:54 a.m.
New subject: [Soa-tools-list] Example of why consistent jar usage is important
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.
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.
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
>
4:42 p.m.
New subject: [Soa-tools-list] Example of why consistent jar usage is important
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
>
4:47 p.m.
New subject: [Soa-tools-list] Example of why consistent jar usage is important
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
> >>
> >
>
4:48 p.m.
New subject: [Soa-tools-list] Example of why consistent jar usage is important
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
>>>>
5:05 p.m.
New subject: [Soa-tools-list] Example of why consistent jar usage is important
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?
-- 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
> > > > > >
> >
> >
>
6:14 a.m.
New subject: [Soa-tools-list] Example of why consistent jar usage is important
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
>>>>>>
>>>>>>
>>
>>
6:29 a.m.
New subject: [Soa-tools-list] Example of why consistent jar usage is important
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 ?
The original error maybe caused by the ESB
client example projects,
it seems that ESB and AS cp container of the ESB client projects
have the wrong order, I will update all ESB project and client project
examples with the right classpath order.
> 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?)
I
don't think creating a "ESB client project" wizard or facet can solve
this problem, since the ESB client can be any types of
project, such as java project, ESB project and sometimes it's might be a
J2ee project, all need to for ESB client is just adding
ESB classpath to the project, so I think we can just provide a popup
menu "Set Up ESB Classpath" by pop up a wizard to select
all available ESB classpath container.
Denny
/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
>>
>
2:01 p.m.
New subject: [Soa-tools-list] Example of why consistent jar usage is important
> We can help by creating a "ESB client project" wizard
(or facet?)
I don't think creating a "ESB client project" wizard or facet can
solve this problem, since the ESB client can be any types of
project, such as java project, ESB project and sometimes it's might be
a J2ee project, all need to for ESB client is just adding
ESB classpath to the project,
The same can be said about any type of java project
in eclipse - they
can all be configured manually if you want ;)
It would solve it in the sense users could see how it should work - but
if we don't need a ESB client project then i'm fine with that;
I think there are too many specialized project wizards in eclipse already ;)
so I think we can just provide a popup menu "Set Up ESB
Classpath" by
pop up a wizard to select
all available ESB classpath container.
I don't understand what that does
differently than adding ESB classpath
under standard classpath dialog for java projects ?
/max
Denny
>
> /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
>>>
>>
>
6:16 p.m.
New subject: [Soa-tools-list] Example of why consistent jar usage is important
>> 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.
afaik, the server needs to support your ESB facet to deploy
it.
>
> 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.
Sure, I'm not saying to *remove* the ESB classpath container, but I'm
saying that in the case of
the runtime is *embedded* inside the server runtime it would make sense
that the server runtime
provides the classpath instead of the separate ESB classpath container.
But lets get back to seeing what we can do now.
We haven't heard why there are different .jar's yet but I guess the
thing we can do know is to ensure that the ESB classpath container
gets added in front of the server runtime - that should solve this
issue, right ?
/max
5544
days inactive
5547
days old
jbosstools-dev@lists.jboss.org
13 comments
3 participants
participants (3)
-
Denny Xu -
John Graham -
Max Rydahl Andersen