Home » Archived » Service Oriented Architecture Tools Platform (STP) » Re: [stp-newsgroup] classes exclusion for runtime version
| Re: [stp-newsgroup] classes exclusion for runtime version [message #374030] |
Wed, 12 July 2006 07:28  |
 keanu
Messages: 49
Registered: July 2009 |
Member |
|
|
This is a multipart message in MIME format.
--=_alternative 00293611492571A9_=
Content-Type: text/plain; charset="US-ASCII"
Hi, Antony,
> My wife and baby girl are fine and very happy thanks. Good luck with
> August :)
Thank you very much.
> I think I see what you mean with the WSDL generation. You mean generate
> the WSDL that describes the BPEL web service? I hadn't thought about
> that to be honest. There are areas where the BPEL relies on the WSDL
> for information like for binding information etc so you couldn't run the
> BPEL without first having the WSDL for it, but you might be able to
> generate basic WSDL for it which you could then fill in the missing
> pieces? Is that what you had in mind?
Right. Yeah, I am just asking you. I can handle this with manual work. So
than's fine.
> I should say that B2J isn't really aiming to provide any tooling for
> creating the BPEL - that would be left to something like the
> BPEL-designer project.
Right. The rest of the stp project will be somehow related on this
modeling projects.
So, is there any integration plan you have with the modeling projects
making visual diagram
such as stp core framework, stp service creation, etc?
>
> The pluggable runtime and the ability of the runtime to run standalone
> are not really tied to each other. The current B2J runtime is capable
> of running standalone today and supports much of BPEL.
>
> The pluggability aspect is about making the B2J interfaces public so
> that other Java runtimes may be written that use some of the same BPEL
> to Java translation code. If you're happy with the capabilities of the
> current runtime then you wouldn't need the pluggability aspect. If you
> were planning on writing your own Java runtime that uses the BPEL to
> Java translation then you would need it. Would you want to replace the
> current runtime with your own runtime or do you just need the current
> runtime to run standalone?
Oh, I see. You are right. Standalone for now.
In the future, 3-4 months later, I will need to extend the runtime to add
some additional functionalities, though.
In terms of pluggability, I mean what we have been discussed about.
I suggested to you whether I can separate out the runtime module from the
whole plugin - "org.eclipse.stp.b2j.core".
Then you have made and published "runtime build" ant file to build runtime
only version.
However, it is just proof of concept level, so , for example, actual codes
that depends on UI or debug are in the runtime-only jar.
Also it has some dependency with j2se APIs - looking for xml in the java
runtime.
Thank you very much for your answer, again.
Regards,
Keanu
>
> thanks
>
> Antony
>
> YoungSang Paik wrote:
> >
> > Antony,
> >
> > Oh, I am very glad to hear that. How is your baby? How is your wife?
> > I am also expecting a baby. Delivery date is expected to be August.
> > Gonglatulations!
> >
> > For the WSDL, I mean the generation of WSDL that goes with BPEL. I
mean
> > the WSDL that BPEL represents.
> >
> > For the pluggable runtime (= runtime only version, I mean), I expect
so
> > because the concept actually coinsides with the b2j architecture.
> > The concept : Runtime is pluggable so that the runtime only module can
> > run standalone
> >
> > If it takes long time, it is sad to hear that.
> > I hope it can be available soon.
> >
> > Thank you for your information.
> > And conglatulation, again!
> > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
> > Paik, YoungSang (Keanu)
> > Advanced Mobile Solution Technology Team in Ubiquitous Computing Lab
(UCL)
> > IBM, Korea
> >
> > Tel: (822)3781-7509, (8211)898-7509 Email: yspaik@kr.ibm.com
> > Address : The MMAA Bldg 467-12 Dogok-dong. Gangnam-gu, Seoul, Korea
> >
> >
> >
> > *Antony Miguel <antony.miguel@scapatech.com>*
> > Sent by: stp-newsgroup-bounces@eclipse.org
> >
> > 06/28/2006 10:33 PM
> > Please respond to
> > "Gateway between eclipse.stp and stp-newsgroup"
<stp-newsgroup@eclipse.org>
> >
> >
> >
> > To
> > stp-newsgroup@eclipse.org
> > cc
> >
> > Subject
> > Re: [stp-newsgroup] classes exclusion for runtime version
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi Keanu,
> >
> > Sorry for the extended delay in my response, I've been off from work
for
> > the past few weeks having a baby.
> >
> > To answer your questions:
> >
> > - I was not aware of the lack of a link to STP mailing lists, I'm not
> > exactly sure where it would go but I'll speak to someone in STP about
it
> > and try to get it sorted.
> >
> > - B2J does not currently support generating Java SOAP clients from
WSDL
> > or generating WSDL from Java classes. B2J's Java binding is based on
> > the Apache WSIF Java binding however so WSDL generated using wsif
should
> > work with B2J. In addition B2J does have both a SOAP server and SOAP
> > client implementation but the SOAP client does not automatically
> > translate anything based on WSDL - it only really deals with the SOAP
> > envelope and HTTP etc.
> >
> > What exactly are you looking for in terms of client generation? If
you
> > expose a service with B2J then you naturally must have WSDL to
describe
> > it so I assume you are after something like a tool to generate a Java
> > API (going via SOAP) to that service? Is that accurate? Something
like
> > this could potentially be implemented in B2J.
> >
> > - As far as the pluggable runtime. I intend to post a plan soon to
the
> > B2J website and newsgroups which will set out a roadmap for producing
> > public APIs to fully integrate BPEL engines and servers into the B2J
> > framework. As things stand, B2J provides good functionality but I do
> > not believe that the current interfaces, if made public as APIs, would
> > fit well with BPEL servers (basically there are assumptions in the B2J
> > framework which are a result of the requirements of the BPEL engine,
> > rather than a more general outlook of BPEL engines and servers).
> >
> > If you plan to use the B2J APIs to implement your own pluggable engine
> > or server then your feedback and requirements would be extremely
useful.
> > I will try to advertise for feedback as widely as possible when I
post
> > the plan.
> >
> > I should also say that this plan will probably not be short term as I
> > expect the process of creating and implementing the plan to take some
> > time. I would be interested to hear what your timescales would be for
> > using B2J also?
> >
> > thanks
> >
> > Antony
> >
> >
> > YoungSang Paik wrote:
> > >
> > > Hi, Antony
> > >
> > > It's been a long time. How have you been?
> > >
> > >
> > > I have a couple of questions.
> > > - I wonder stp mailing list link is not shown on the eclipse web
site.
> > > Do you know that?
> > > - Can I make a SOAP client for the service that BPEL script is
exposing?
> > > I mean, can b2j engine create WSDL just as Axis can generate WSDL
for a
> > > particular service so that SOAP client can be generated according
to the
> > > WSDL?
> > > - Could I share any news for your pluggable b2j runtime?
> > >
> > > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
> > > Paik, YoungSang (Keanu)
> > > Advanced Mobile Solution Technology Team in Ubiquitous Computing
Lab
> > (UCL)
> > > IBM, Korea
> > >
> > > Tel: (822)3781-7509, (8211)898-7509 Email: yspaik@kr.ibm.com
> > > Address : The MMAA Bldg 467-12 Dogok-dong. Gangnam-gu, Seoul, Korea
> > >
> > >
> > >
> > > *Antony Miguel <antony.miguel@scapatech.com>*
> > > Sent by: stp-newsgroup-bounces@eclipse.org
> > >
> > > 05/16/2006 02:24 AM
> > > Please respond to
> > > "Gateway between eclipse.stp and stp-newsgroup"
> > <stp-newsgroup@eclipse.org>
> > >
> > >
> > >
> > > To
> > > stp-newsgroup@eclipse.org
> > > cc
> > >
> > > Subject
> > > Re: [stp-newsgroup] classes exclusion for runtime
> > version
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi Keanu,
> > >
> > > I've written one test class that generates an engine program and
saves
> > > it to disk, and another test class that uses just the local engine
to
> > > run the compiled program (these would represent your client side
BPEL
> > > compilation step and your embedded device BPEL execution step).
> > >
> > > I've used these test classes to chop out bits of unused code from
the
> > > runtime only JAR including the distributed engine and make sure the
> > > runtime only test program can still run BPEL using only the
cut-down JAR.
> > >
> > > The resulting runtime only JAR which is still able to run the
> > > precompiled BPEL files I mentioned below (test_xpath,
test_messaging,
> > > test_soapserver_pick) is 304KB. This should need no extra
libraries to
> > > run on CDC/FP 1.0 or Java 1.3.
> > >
> > > cheers
> > >
> > > Antony
> > >
> > > Antony Miguel wrote:
> > > > Hi Keanu,
> > > >
> > > > I have converted B2J to use it's own XML parser, got the HTTP
> > > > implementation to load JSSE via reflection and removed all 1.4
JVM
> > > > library dependencies from B2J core (there were a few odd extra
> > > > references such as java.net.URI).
> > > >
> > > > The end result is that the whole of B2J core (including the
> > compilation
> > > > stages - given that javac or some other compiler is present) can
> > now run
> > > > using:
> > > >
> > > > - IBM WEME 6.1 lnx-x86-ppro10 (which I believe is CDC/FP 1.0?)
> > > > - Sun CVM CDC/FP 1.1
> > > >
> > > > Given that it runs on the above IBM WEME JVM it should also run
OK on
> > > > Sun CVM CDC/FP 1.0 but I haven't been able to build that JVM
yet.
> > > >
> > > > I've been able to run almost all of the example BPEL files. In
> > > > particular on both JVMs I have successfully run
> > > >
> > > > - test_xpath.bpel
> > > > - test_soapserver_pick.bpel
> > > > - test_messaging.bpel
> > > >
> > > > I think these constitute a reasonable all-round test. They
> > include use
> > > > of HTTP/SOAP, XPATH and heavy threading and synchronisation.
> > > >
> > > > Including the new XML parser and all changes the full core JAR
> > stands at
> > > > about 745KB. The runtime only JAR stands at 442KB (but this
still
> > > > includes the distributed engine).
> > > >
> > > > I plan to do some more thorough testing as one or two of the
example
> > > > files fail (for reasons which may or may be related to recent
changes)
> > > > but I don't see any real reason why these changes couldn't go
into the
> > > > B2J main stream. They don't in any way degrade the performance
of B2J
> > > > and they make it more flexible in it's requirements.
> > > >
> > > > Are these the right JVMs and CDC/FP specifications you were
hoping
> > for?
> > > >
> > > > thanks
> > > >
> > > > Antony
> > > >
> > > > Antony Miguel wrote:
> > > >
> > > >> Hi Keanu,
> > > >>
> > > >>>> This may not work in other JVMs, I think in my previous
experience
> > > >>>> it might break in an IBM JVM but I'm not sure.
> > > >>>
> > > >>>
> > > >>>
> > > >>> Oh, Really? For me, b2j still works fine with IBM sdk v 1.4.
> > > >>> my version is
> > > >>> - java fullversion "J2RE 1.4.2 IBM Windows 32 build
cn142-20050609
> > > >>
> > > >>
> > > >>
> > > >> This was just me remembering an issue from a long time ago. I
think
> > > >> that once upon a time I saw some very subtle difference to do
with
> > > >> classloading but like I say I can't remember exactly what the
> > deal was
> > > >> (it was complicated). It occurred to me that if you were
having
> > > >> NoClassDefErrors thrown then it could be this issue again but
if it
> > > >> works fine for you on an IBM JVM then I expect it was a
different
> > issue.
> > > >>
> > > >>> Only exception I have noticed in b2j is java.io.EOFException
> > with the
> > > >>> test bpel script when I tested with distributed engines. (It
is a
> > > >>> endurable bug for now. I know b2j is still developing phase.)
But I
> > > >>> have not noticed any "error" messages from VM, not the
exception
> > > >>> messages from program, during the test run.
> > > >>
> > > >>
> > > >>
> > > >> That's not so good. Can you tell me what script it is
thatfails and
> > > >> email me the EOFException stacktrace please?
> > > >>
> > > >> Does it only occur with the distributed engine?
> > > >>
> > > >>> Oh, I see. Yes, I am temporarily doing with the full B2J jar
on a
> > > >>> common PC. I am transitting from design phase to development
phase.
> > > >>> Feasibility is the main activity. Right. Sure, I will wait.
> > > >>> I really appreciate you effort.
> > > >>
> > > >>
> > > >>
> > > >> No problem, I am making progress with the conversion to the B2J
XML
> > > >> parser and it seems like it will be feasible to make B2J use it
all
> > > >> over (B2J has turned out to be quite a thorough test of my XML
parser
> > > >> and thrown up a variety of bugs). It adds a total of 16.5K to
> > the jar
> > > >> (compressed) and would mean (i think) that the only requirement
would
> > > >> be for JSSE libraries, which I should be able to remove just by
using
> > > >> reflection and catching the ClassNotFoundException. These
changes
> > > >> (plus perhaps one or two other ones I expect I have missed)
should
> > > >> make B2J able to run with only 1.3 JVM libraries. Once thats
done I
> > > >> will try running on a Java ME JVM.
> > > >>
> > > >> thanks
> > > >>
> > > >> Antony
> > > _______________________________________________
> > > stp-newsgroup mailing list
> > > stp-newsgroup@eclipse.org
> > > https://dev.eclipse.org/mailman/listinfo/stp-newsgroup
> > >
> > _______________________________________________
> > stp-newsgroup mailing list
> > stp-newsgroup@eclipse.org
> > https://dev.eclipse.org/mailman/listinfo/stp-newsgroup
> >
> _______________________________________________
> stp-newsgroup mailing list
> stp-newsgroup@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/stp-newsgroup
--=_alternative 00293611492571A9_=
Content-Type: text/html; charset="US-ASCII"
<br><tt><font size=2>Hi, Antony,</font></tt>
<br>
<br><tt><font size=2>> My wife and baby girl are fine and very happy
thanks. Good luck with <br>
> August :)<br>
Thank you very much.</font></tt>
<br>
<br>
<br><tt><font size=2>> I think I see what you mean with the WSDL generation.
You mean generate <br>
> the WSDL that describes the BPEL web service? I hadn't thought
about <br>
> that to be honest. There are areas where the BPEL relies on
the WSDL <br>
> for information like for binding information etc so you couldn't run
the <br>
> BPEL without first having the WSDL for it, but you might be able to
<br>
> generate basic WSDL for it which you could then fill in the missing
<br>
> pieces? Is that what you had in mind?</font></tt>
<br><tt><font size=2>Right. Yeah, I am just asking you. I can handle this
with manual work. So than's fine.</font></tt>
<br>
<br>
<br><tt><font size=2>> I should say that B2J isn't really aiming to
provide any tooling for <br>
> creating the BPEL - that would be left to something like the <br>
> BPEL-designer project.<br>
Right. The rest of the stp project will be somehow related on this modeling
projects.</font></tt>
<br><tt><font size=2>So, is there any integration plan you have with the
modeling projects making visual diagram </font></tt>
<br><tt><font size=2>such as stp core framework, stp service creation,
etc?</font></tt>
<br>
<br>
<br><tt><font size=2>> <br>
> The pluggable runtime and the ability of the runtime to run standalone
<br>
> are not really tied to each other. The current B2J runtime is
capable <br>
> of running standalone today and supports much of BPEL.<br>
> <br>
> The pluggability aspect is about making the B2J interfaces public
so <br>
> that other Java runtimes may be written that use some of the same
BPEL <br>
> to Java translation code. If you're happy with the capabilities
of the <br>
> current runtime then you wouldn't need the pluggability aspect. If
you <br>
> were planning on writing your own Java runtime that uses the BPEL
to <br>
> Java translation then you would need it. Would you want to replace
the <br>
> current runtime with your own runtime or do you just need the current
<br>
> runtime to run standalone?</font></tt>
<br>
<br><tt><font size=2>Oh, I see. You are right. Standalone for now. </font></tt>
<br><tt><font size=2>In the future, 3-4 months later, I will need to extend
the runtime to add some additional functionalities, though.</font></tt>
<br><tt><font size=2>In terms of pluggability, I mean what we have been
discussed about.</font></tt>
<br><tt><font size=2>I suggested to you whether I can separate out the
runtime module from the whole plugin - "org.eclipse.stp.b2j.core".</font></tt>
<br><tt><font size=2>Then you have made and published "runtime build"
ant file to build runtime only version.</font></tt>
<br><tt><font size=2>However, it is just proof of concept level, so , for
example, actual codes that depends on UI or debug are in the runtime-only
jar.</font></tt>
<br><tt><font size=2>Also it has some dependency with j2se APIs - looking
for xml in the java runtime. </font></tt>
<br>
<br>
<br><tt><font size=2>Thank you very much for your answer, again.</font></tt>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Keanu </font></tt>
<br>
<br>
<br>
<br>
<br><tt><font size=2><br>
> <br>
> thanks<br>
> <br>
> Antony<br>
> <br>
> YoungSang Paik wrote:<br>
> > <br>
> > Antony,<br>
> > <br>
> > Oh, I am very glad to hear that. How is your baby? How is your
wife?<br>
> > I am also expecting a baby. Delivery date is expected to be August.<br>
> > Gonglatulations!<br>
> > <br>
> > For the WSDL, I mean the generation of WSDL that goes with BPEL.
I mean <br>
> > the WSDL that BPEL represents.<br>
> > <br>
> > For the pluggable runtime (= runtime only version, I mean), I
expect so <br>
> > because the concept actually coinsides with the b2j architecture.<br>
> > The concept : Runtime is pluggable so that the runtime only module
can <br>
> > run standalone<br>
> > <br>
> > If it takes long time, it is sad to hear that.<br>
> > I hope it can be available soon.<br>
> > <br>
> > Thank you for your information.<br>
> > And conglatulation, again!<br>
> > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+<br>
> > Paik, YoungSang (Keanu)<br>
> > Advanced Mobile Solution Technology Team in Ubiquitous Computing
Lab (UCL)<br>
> > IBM, Korea<br>
> > <br>
> > Tel: (822)3781-7509, (8211)898-7509 Email: yspaik@kr.ibm.com<br>
> > Address : The MMAA Bldg 467-12 Dogok-dong. Gangnam-gu, Seoul,
Korea<br>
> > <br>
> > <br>
> > <br>
> > *Antony Miguel <antony.miguel@scapatech.com>*<br>
> > Sent by: stp-newsgroup-bounces@eclipse.org<br>
> > <br>
> > 06/28/2006 10:33 PM<br>
> > Please respond to<br>
> > "Gateway between eclipse.stp and stp-newsgroup" <stp-newsgroup@eclipse.org><br>
> > <br>
> > <br>
> > <br>
> > To<br>
> > stp-newsgroup@eclipse.org<br>
> > cc<br>
> > <br>
> > Subject<br>
> > Re: [stp-newsgroup] classes exclusion for runtime
version<br>
> > <br>
> > <br>
> > <br>
> > <br>
> > <br>
> > <br>
> > <br>
> > <br>
> > Hi Keanu,<br>
> > <br>
> > Sorry for the extended delay in my response, I've been off from
work for<br>
> > the past few weeks having a baby.<br>
> > <br>
> > To answer your questions:<br>
> > <br>
> > - I was not aware of the lack of a link to STP mailing lists,
I'm not<br>
> > exactly sure where it would go but I'll speak to someone in STP
about it<br>
> > and try to get it sorted.<br>
> > <br>
> > - B2J does not currently support generating Java SOAP clients
from WSDL<br>
> > or generating WSDL from Java classes. B2J's Java binding
is based on<br>
> > the Apache WSIF Java binding however so WSDL generated using
wsif should<br>
> > work with B2J. In addition B2J does have both a SOAP server
and SOAP<br>
> > client implementation but the SOAP client does not automatically<br>
> > translate anything based on WSDL - it only really deals with
the SOAP<br>
> > envelope and HTTP etc.<br>
> > <br>
> > What exactly are you looking for in terms of client generation?
If you<br>
> > expose a service with B2J then you naturally must have WSDL to
describe<br>
> > it so I assume you are after something like a tool to generate
a Java<br>
> > API (going via SOAP) to that service? Is that accurate?
Something like<br>
> > this could potentially be implemented in B2J.<br>
> > <br>
> > - As far as the pluggable runtime. I intend to post a plan
soon to the<br>
> > B2J website and newsgroups which will set out a roadmap for producing<br>
> > public APIs to fully integrate BPEL engines and servers into
the B2J<br>
> > framework. As things stand, B2J provides good functionality
but I do<br>
> > not believe that the current interfaces, if made public as APIs,
would<br>
> > fit well with BPEL servers (basically there are assumptions in
the B2J<br>
> > framework which are a result of the requirements of the BPEL
engine,<br>
> > rather than a more general outlook of BPEL engines and servers).<br>
> > <br>
> > If you plan to use the B2J APIs to implement your own pluggable
engine<br>
> > or server then your feedback and requirements would be extremely
useful.<br>
> > I will try to advertise for feedback as widely as possible
when I post<br>
> > the plan.<br>
> > <br>
> > I should also say that this plan will probably not be short term
as I<br>
> > expect the process of creating and implementing the plan to take
some<br>
> > time. I would be interested to hear what your timescales
would be for<br>
> > using B2J also?<br>
> > <br>
> > thanks<br>
> > <br>
> > Antony<br>
> > <br>
> > <br>
> > YoungSang Paik wrote:<br>
> > ><br>
> > > Hi, Antony<br>
> > ><br>
> > > It's been a long time. How have you been?<br>
> > ><br>
> > ><br>
> > > I have a couple of questions.<br>
> > > - I wonder stp mailing list link is not shown on the
eclipse web site.<br>
> > > Do you know that?<br>
> > > - Can I make a SOAP client for the service that BPEL
script is exposing?<br>
> > > I mean, can b2j engine create WSDL just as Axis can
generate WSDL for a<br>
> > > particular service so that SOAP client can be generated
according to the<br>
> > > WSDL?<br>
> > > - Could I share any news for your pluggable b2j runtime?<br>
> > ><br>
> > > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+<br>
> > > Paik, YoungSang (Keanu)<br>
> > > Advanced Mobile Solution Technology Team in Ubiquitous
Computing Lab <br>
> > (UCL)<br>
> > > IBM, Korea<br>
> > ><br>
> > > Tel: (822)3781-7509, (8211)898-7509 Email: yspaik@kr.ibm.com<br>
> > > Address : The MMAA Bldg 467-12 Dogok-dong. Gangnam-gu,
Seoul, Korea<br>
> > ><br>
> > ><br>
> > ><br>
> > > *Antony Miguel <antony.miguel@scapatech.com>*<br>
> > > Sent by: stp-newsgroup-bounces@eclipse.org<br>
> > ><br>
> > > 05/16/2006 02:24 AM<br>
> > > Please respond to<br>
> > > "Gateway between eclipse.stp and stp-newsgroup"
<br>
> > <stp-newsgroup@eclipse.org><br>
> > ><br>
> > ><br>
> > >
<br>
> > > To<br>
> > >
stp-newsgroup@eclipse.org<br>
> > > cc<br>
> > >
<br>
> > > Subject<br>
> > >
Re: [stp-newsgroup] classes exclusion for runtime <br>
> > version<br>
> > ><br>
> > ><br>
> > >
<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > Hi Keanu,<br>
> > ><br>
> > > I've written one test class that generates an engine
program and saves<br>
> > > it to disk, and another test class that uses just
the local engine to<br>
> > > run the compiled program (these would represent your
client side BPEL<br>
> > > compilation step and your embedded device BPEL execution
step).<br>
> > ><br>
> > > I've used these test classes to chop out bits of unused
code from the<br>
> > > runtime only JAR including the distributed engine
and make sure the<br>
> > > runtime only test program can still run BPEL using
only the cut-down JAR.<br>
> > ><br>
> > > The resulting runtime only JAR which is still able
to run the<br>
> > > precompiled BPEL files I mentioned below (test_xpath,
test_messaging,<br>
> > > test_soapserver_pick) is 304KB. This should
need no extra libraries to<br>
> > > run on CDC/FP 1.0 or Java 1.3.<br>
> > ><br>
> > > cheers<br>
> > ><br>
> > > Antony<br>
> > ><br>
> > > Antony Miguel wrote:<br>
> > > > Hi Keanu,<br>
> > > ><br>
> > > > I have converted B2J to use it's own XML
parser, got the HTTP<br>
> > > > implementation to load JSSE via reflection
and removed all 1.4 JVM<br>
> > > > library dependencies from B2J core (there
were a few odd extra<br>
> > > > references such as java.net.URI).<br>
> > > ><br>
> > > > The end result is that the whole of B2J
core (including the <br>
> > compilation<br>
> > > > stages - given that javac or some other
compiler is present) can <br>
> > now run<br>
> > > > using:<br>
> > > ><br>
> > > > - IBM WEME 6.1 lnx-x86-ppro10 (which
I believe is CDC/FP 1.0?)<br>
> > > > - Sun CVM CDC/FP 1.1<br>
> > > ><br>
> > > > Given that it runs on the above IBM WEME
JVM it should also run OK on<br>
> > > > Sun CVM CDC/FP 1.0 but I haven't been able
to build that JVM yet.<br>
> > > ><br>
> > > > I've been able to run almost all of the
example BPEL files. In<br>
> > > > particular on both JVMs I have successfully
run<br>
> > > ><br>
> > > > - test_xpath.bpel<br>
> > > > - test_soapserver_pick.bpel<br>
> > > > - test_messaging.bpel<br>
> > > ><br>
> > > > I think these constitute a reasonable all-round
test. They <br>
> > include use<br>
> > > > of HTTP/SOAP, XPATH and heavy threading
and synchronisation.<br>
> > > ><br>
> > > > Including the new XML parser and all changes
the full core JAR <br>
> > stands at<br>
> > > > about 745KB. The runtime only JAR
stands at 442KB (but this still<br>
> > > > includes the distributed engine).<br>
> > > ><br>
> > > > I plan to do some more thorough testing
as one or two of the example<br>
> > > > files fail (for reasons which may or may
be related to recent changes)<br>
> > > > but I don't see any real reason why these
changes couldn't go into the<br>
> > > > B2J main stream. They don't in any
way degrade the performance of B2J<br>
> > > > and they make it more flexible in it's
requirements.<br>
> > > ><br>
> > > > Are these the right JVMs and CDC/FP specifications
you were hoping <br>
> > for?<br>
> > > ><br>
> > > > thanks<br>
> > > ><br>
> > > > Antony<br>
> > > ><br>
> > > > Antony Miguel wrote:<br>
> > > ><br>
> > > >> Hi Keanu,<br>
> > > >><br>
> > > >>>> This may not work in
other JVMs, I think in my previous experience<br>
> > > >>>> it might break in an IBM JVM
but I'm not sure.<br>
> > > >>><br>
> > > >>><br>
> > > >>><br>
> > > >>> Oh, Really? For me, b2j still works
fine with IBM sdk v 1.4.<br>
> > > >>> my version is<br>
> > > >>> - java fullversion "J2RE 1.4.2
IBM Windows 32 build cn142-20050609<br>
> > > >><br>
> > > >><br>
> > > >><br>
> > > >> This was just me remembering an issue
from a long time ago. I think<br>
> > > >> that once upon a time I saw some very
subtle difference to do with<br>
> > > >> classloading but like I say I can't
remember exactly what the <br>
> > deal was<br>
> > > >> (it was complicated). It occurred
to me that if you were having<br>
> > > >> NoClassDefErrors thrown then it could
be this issue again but if it<br>
> > > >> works fine for you on an IBM JVM then
I expect it was a different <br>
> > issue.<br>
> > > >><br>
> > > >>> Only exception I have noticed in
b2j is java.io.EOFException <br>
> > with the<br>
> > > >>> test bpel script when I tested
with distributed engines. (It is a<br>
> > > >>> endurable bug for now. I know b2j
is still developing phase.) But I<br>
> > > >>> have not noticed any "error"
messages from VM, not the exception<br>
> > > >>> messages from program, during the
test run.<br>
> > > >><br>
> > > >><br>
> > > >><br>
> > > >> That's not so good. Can you tell
me what script it is thatfails and<br>
> > > >> email me the EOFException stacktrace
please?<br>
> > > >><br>
> > > >> Does it only occur with the distributed
engine?<br>
> > > >><br>
> > > >>> Oh, I see. Yes, I am temporarily
doing with the full B2J jar on a<br>
> > > >>> common PC. I am transitting from
design phase to development phase.<br>
> > > >>> Feasibility is the main activity.
Right. Sure, I will wait.<br>
> > > >>> I really appreciate you effort.<br>
> > > >><br>
> > > >><br>
> > > >><br>
> > > >> No problem, I am making progress with
the conversion to the B2J XML<br>
> > > >> parser and it seems like it will be
feasible to make B2J use it all<br>
> > > >> over (B2J has turned out to be quite
a thorough test of my XML parser<br>
> > > >> and thrown up a variety of bugs). It
adds a total of 16.5K to <br>
> > the jar<br>
> > > >> (compressed) and would mean (i think)
that the only requirement would<br>
> > > >> be for JSSE libraries, which I should
be able to remove just by using<br>
> > > >> reflection and catching the ClassNotFoundException.
These changes<br>
> > > >> (plus perhaps one or two other ones
I expect I have missed) should<br>
> > > >> make B2J able to run with only 1.3
JVM libraries. Once thats done I<br>
> > > >> will try running on a Java ME JVM.<br>
> > > >><br>
> > > >> thanks<br>
> > > >><br>
> > > >> Antony<br>
> > > _______________________________________________<br>
> > > stp-newsgroup mailing list<br>
> > > stp-newsgroup@eclipse.org<br>
> > > https://dev.eclipse.org/mailman/listinfo/stp-newsgroup<br>
> > ><br>
> > _______________________________________________<br>
> > stp-newsgroup mailing list<br>
> > stp-newsgroup@eclipse.org<br>
> > https://dev.eclipse.org/mailman/listinfo/stp-newsgroup<br>
> > <br>
> _______________________________________________<br>
> stp-newsgroup mailing list<br>
> stp-newsgroup@eclipse.org<br>
> https://dev.eclipse.org/mailman/listinfo/stp-newsgroup<br>
</font></tt>
--=_alternative 00293611492571A9_=--
|
|
|
| Re: [stp-newsgroup] classes exclusion for runtime version [message #374033 is a reply to message #374030] |
Tue, 18 July 2006 10:28  |
Antony Miguel
Messages: 49
Registered: July 2009 |
Member |
|
|
Hi Keanu,
I've checked in some changes to B2J based on the changes we talk about
some time ago.
The latest B2J Core code in CVS now has no dependencies on a 1.4JVM and
you can use the build.xml to build a runtime only distribution.
I've tried this version on a 1.3 JVM and I've tried it on the J2ME JVMs
I mentioned before.
You can use the build.xml to build a runtime-only B2J.jar and then you
can use:
JVM_1.3\bin\java -cp b2j.jar
org.eclipse.stp.b2j.core.jengine.internal.mainengine.SoapDae mon
to run the distributed B2J engine daemon, then you can use the standard
Eclipse workbench to run a 'distributed' BPEL process on just that
target host or device.
To answer your previous questions:
I don't have any plans to integrate with any particular BPEL design
tools but I do plan to integrate with the STP deployment framework when
it is ready for integration.
The BPEL design tools I would imagine would just produce BPEL, so I
would see BPEL as the integration point there. I can imagine the BPEL
design tools and any deployment frameworks might want to integrate, and
then I would integrate B2J with the deployment frameworks.
I think the runtime build of the latest B2J code should satisfy the
requirements we talked about. It's no longer dependant on J2SE
libraries and there is no *live* code that is dependant on any UI
libraries etc when you are just running B2J as a runtime. As I said
above you should be able to just include the runtime built b2j.jar with
a 1.3 JVM and you should get no ClassDefNotFound errors.
Hopefully this puts B2J on the right track for you to be able to use it
but please let me know if there are any areas you have trouble with or
any other requirements you have.
thanks
Antony
YoungSang Paik wrote:
>
> Hi, Antony,
>
> > My wife and baby girl are fine and very happy thanks. Good luck with
> > August :)
> Thank you very much.
>
>
> > I think I see what you mean with the WSDL generation. You mean generate
> > the WSDL that describes the BPEL web service? I hadn't thought about
> > that to be honest. There are areas where the BPEL relies on the WSDL
> > for information like for binding information etc so you couldn't run the
> > BPEL without first having the WSDL for it, but you might be able to
> > generate basic WSDL for it which you could then fill in the missing
> > pieces? Is that what you had in mind?
> Right. Yeah, I am just asking you. I can handle this with manual work.
> So than's fine.
>
>
> > I should say that B2J isn't really aiming to provide any tooling for
> > creating the BPEL - that would be left to something like the
> > BPEL-designer project.
> Right. The rest of the stp project will be somehow related on this
> modeling projects.
> So, is there any integration plan you have with the modeling projects
> making visual diagram
> such as stp core framework, stp service creation, etc?
>
>
> >
> > The pluggable runtime and the ability of the runtime to run standalone
> > are not really tied to each other. The current B2J runtime is capable
> > of running standalone today and supports much of BPEL.
> >
> > The pluggability aspect is about making the B2J interfaces public so
> > that other Java runtimes may be written that use some of the same BPEL
> > to Java translation code. If you're happy with the capabilities of the
> > current runtime then you wouldn't need the pluggability aspect. If you
> > were planning on writing your own Java runtime that uses the BPEL to
> > Java translation then you would need it. Would you want to replace the
> > current runtime with your own runtime or do you just need the current
> > runtime to run standalone?
>
> Oh, I see. You are right. Standalone for now.
> In the future, 3-4 months later, I will need to extend the runtime to
> add some additional functionalities, though.
> In terms of pluggability, I mean what we have been discussed about.
> I suggested to you whether I can separate out the runtime module from
> the whole plugin - "org.eclipse.stp.b2j.core".
> Then you have made and published "runtime build" ant file to build
> runtime only version.
> However, it is just proof of concept level, so , for example, actual
> codes that depends on UI or debug are in the runtime-only jar.
> Also it has some dependency with j2se APIs - looking for xml in the java
> runtime.
>
>
> Thank you very much for your answer, again.
> Regards,
> Keanu
>
>
>
>
>
> >
> > thanks
> >
> > Antony
> >
> > YoungSang Paik wrote:
> > >
> > > Antony,
> > >
> > > Oh, I am very glad to hear that. How is your baby? How is your wife?
> > > I am also expecting a baby. Delivery date is expected to be August.
> > > Gonglatulations!
> > >
> > > For the WSDL, I mean the generation of WSDL that goes with BPEL. I
> mean
> > > the WSDL that BPEL represents.
> > >
> > > For the pluggable runtime (= runtime only version, I mean), I
> expect so
> > > because the concept actually coinsides with the b2j architecture.
> > > The concept : Runtime is pluggable so that the runtime only module can
> > > run standalone
> > >
> > > If it takes long time, it is sad to hear that.
> > > I hope it can be available soon.
> > >
> > > Thank you for your information.
> > > And conglatulation, again!
> > > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
> > > Paik, YoungSang (Keanu)
> > > Advanced Mobile Solution Technology Team in Ubiquitous Computing
> Lab (UCL)
> > > IBM, Korea
> > >
> > > Tel: (822)3781-7509, (8211)898-7509 Email: yspaik@kr.ibm.com
> > > Address : The MMAA Bldg 467-12 Dogok-dong. Gangnam-gu, Seoul, Korea
> > >
> > >
> > >
> > > *Antony Miguel <antony.miguel@scapatech.com>*
> > > Sent by: stp-newsgroup-bounces@eclipse.org
> > >
> > > 06/28/2006 10:33 PM
> > > Please respond to
> > > "Gateway between eclipse.stp and stp-newsgroup"
> <stp-newsgroup@eclipse.org>
> > >
> > >
> > >
> > > To
> > > stp-newsgroup@eclipse.org
> > > cc
> > >
> > > Subject
> > > Re: [stp-newsgroup] classes exclusion for runtime version
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi Keanu,
> > >
> > > Sorry for the extended delay in my response, I've been off from
> work for
> > > the past few weeks having a baby.
> > >
> > > To answer your questions:
> > >
> > > - I was not aware of the lack of a link to STP mailing lists, I'm not
> > > exactly sure where it would go but I'll speak to someone in STP
> about it
> > > and try to get it sorted.
> > >
> > > - B2J does not currently support generating Java SOAP clients from WSDL
> > > or generating WSDL from Java classes. B2J's Java binding is based on
> > > the Apache WSIF Java binding however so WSDL generated using wsif
> should
> > > work with B2J. In addition B2J does have both a SOAP server and SOAP
> > > client implementation but the SOAP client does not automatically
> > > translate anything based on WSDL - it only really deals with the SOAP
> > > envelope and HTTP etc.
> > >
> > > What exactly are you looking for in terms of client generation? If you
> > > expose a service with B2J then you naturally must have WSDL to describe
> > > it so I assume you are after something like a tool to generate a Java
> > > API (going via SOAP) to that service? Is that accurate? Something
> like
> > > this could potentially be implemented in B2J.
> > >
> > > - As far as the pluggable runtime. I intend to post a plan soon to the
> > > B2J website and newsgroups which will set out a roadmap for producing
> > > public APIs to fully integrate BPEL engines and servers into the B2J
> > > framework. As things stand, B2J provides good functionality but I do
> > > not believe that the current interfaces, if made public as APIs, would
> > > fit well with BPEL servers (basically there are assumptions in the B2J
> > > framework which are a result of the requirements of the BPEL engine,
> > > rather than a more general outlook of BPEL engines and servers).
> > >
> > > If you plan to use the B2J APIs to implement your own pluggable engine
> > > or server then your feedback and requirements would be extremely
> useful.
> > > I will try to advertise for feedback as widely as possible when I post
> > > the plan.
> > >
> > > I should also say that this plan will probably not be short term as I
> > > expect the process of creating and implementing the plan to take some
> > > time. I would be interested to hear what your timescales would be for
> > > using B2J also?
> > >
> > > thanks
> > >
> > > Antony
> > >
> > >
> > > YoungSang Paik wrote:
> > > >
> > > > Hi, Antony
> > > >
> > > > It's been a long time. How have you been?
> > > >
> > > >
> > > > I have a couple of questions.
> > > > - I wonder stp mailing list link is not shown on the eclipse web
> site.
> > > > Do you know that?
> > > > - Can I make a SOAP client for the service that BPEL script is
> exposing?
> > > > I mean, can b2j engine create WSDL just as Axis can generate
> WSDL for a
> > > > particular service so that SOAP client can be generated
> according to the
> > > > WSDL?
> > > > - Could I share any news for your pluggable b2j runtime?
> > > >
> > > > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
> > > > Paik, YoungSang (Keanu)
> > > > Advanced Mobile Solution Technology Team in Ubiquitous Computing
> Lab
> > > (UCL)
> > > > IBM, Korea
> > > >
> > > > Tel: (822)3781-7509, (8211)898-7509 Email: yspaik@kr.ibm.com
> > > > Address : The MMAA Bldg 467-12 Dogok-dong. Gangnam-gu, Seoul, Korea
> > > >
> > > >
> > > >
> > > > *Antony Miguel <antony.miguel@scapatech.com>*
> > > > Sent by: stp-newsgroup-bounces@eclipse.org
> > > >
> > > > 05/16/2006 02:24 AM
> > > > Please respond to
> > > > "Gateway between eclipse.stp and stp-newsgroup"
> > > <stp-newsgroup@eclipse.org>
> > > >
> > > >
> > > >
> > > > To
> > > > stp-newsgroup@eclipse.org
> > > > cc
> > > >
> > > > Subject
> > > > Re: [stp-newsgroup] classes exclusion for runtime
> > > version
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Hi Keanu,
> > > >
> > > > I've written one test class that generates an engine program and
> saves
> > > > it to disk, and another test class that uses just the local
> engine to
> > > > run the compiled program (these would represent your client side
> BPEL
> > > > compilation step and your embedded device BPEL execution step).
> > > >
> > > > I've used these test classes to chop out bits of unused code
> from the
> > > > runtime only JAR including the distributed engine and make sure the
> > > > runtime only test program can still run BPEL using only the
> cut-down JAR.
> > > >
> > > > The resulting runtime only JAR which is still able to run the
> > > > precompiled BPEL files I mentioned below (test_xpath,
> test_messaging,
> > > > test_soapserver_pick) is 304KB. This should need no extra
> libraries to
> > > > run on CDC/FP 1.0 or Java 1.3.
> > > >
> > > > cheers
> > > >
> > > > Antony
> > > >
> > > > Antony Miguel wrote:
> > > > > Hi Keanu,
> > > > >
> > > > > I have converted B2J to use it's own XML parser, got the HTTP
> > > > > implementation to load JSSE via reflection and removed all
> 1.4 JVM
> > > > > library dependencies from B2J core (there were a few odd extra
> > > > > references such as java.net.URI).
> > > > >
> > > > > The end result is that the whole of B2J core (including the
> > > compilation
> > > > > stages - given that javac or some other compiler is present) can
> > > now run
> > > > > using:
> > > > >
> > > > > - IBM WEME 6.1 lnx-x86-ppro10 (which I believe is CDC/FP 1.0?)
> > > > > - Sun CVM CDC/FP 1.1
> > > > >
> > > > > Given that it runs on the above IBM WEME JVM it should also
> run OK on
> > > > > Sun CVM CDC/FP 1.0 but I haven't been able to build that JVM yet.
> > > > >
> > > > > I've been able to run almost all of the example BPEL files. In
> > > > > particular on both JVMs I have successfully run
> > > > >
> > > > > - test_xpath.bpel
> > > > > - test_soapserver_pick.bpel
> > > > > - test_messaging.bpel
> > > > >
> > > > > I think these constitute a reasonable all-round test. They
> > > include use
> > > > > of HTTP/SOAP, XPATH and heavy threading and synchronisation.
> > > > >
> > > > > Including the new XML parser and all changes the full core JAR
> > > stands at
> > > > > about 745KB. The runtime only JAR stands at 442KB (but this
> still
> > > > > includes the distributed engine).
> > > > >
> > > > > I plan to do some more thorough testing as one or two of the
> example
> > > > > files fail (for reasons which may or may be related to recent
> changes)
> > > > > but I don't see any real reason why these changes couldn't go
> into the
> > > > > B2J main stream. They don't in any way degrade the
> performance of B2J
> > > > > and they make it more flexible in it's requirements.
> > > > >
> > > > > Are these the right JVMs and CDC/FP specifications you were
> hoping
> > > for?
> > > > >
> > > > > thanks
> > > > >
> > > > > Antony
> > > > >
> > > > > Antony Miguel wrote:
> > > > >
> > > > >> Hi Keanu,
> > > > >>
> > > > >>>> This may not work in other JVMs, I think in my previous
> experience
> > > > >>>> it might break in an IBM JVM but I'm not sure.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> Oh, Really? For me, b2j still works fine with IBM sdk v 1.4.
> > > > >>> my version is
> > > > >>> - java fullversion "J2RE 1.4.2 IBM Windows 32 build
> cn142-20050609
> > > > >>
> > > > >>
> > > > >>
> > > > >> This was just me remembering an issue from a long time ago.
> I think
> > > > >> that once upon a time I saw some very subtle difference to
> do with
> > > > >> classloading but like I say I can't remember exactly what the
> > > deal was
> > > > >> (it was complicated). It occurred to me that if you were having
> > > > >> NoClassDefErrors thrown then it could be this issue again
> but if it
> > > > >> works fine for you on an IBM JVM then I expect it was a
> different
> > > issue.
> > > > >>
> > > > >>> Only exception I have noticed in b2j is java.io.EOFException
> > > with the
> > > > >>> test bpel script when I tested with distributed engines.
> (It is a
> > > > >>> endurable bug for now. I know b2j is still developing
> phase.) But I
> > > > >>> have not noticed any "error" messages from VM, not the
> exception
> > > > >>> messages from program, during the test run.
> > > > >>
> > > > >>
> > > > >>
> > > > >> That's not so good. Can you tell me what script it is
> thatfails and
> > > > >> email me the EOFException stacktrace please?
> > > > >>
> > > > >> Does it only occur with the distributed engine?
> > > > >>
> > > > >>> Oh, I see. Yes, I am temporarily doing with the full B2J
> jar on a
> > > > >>> common PC. I am transitting from design phase to
> development phase.
> > > > >>> Feasibility is the main activity. Right. Sure, I will wait.
> > > > >>> I really appreciate you effort.
> > > > >>
> > > > >>
> > > > >>
> > > > >> No problem, I am making progress with the conversion to the
> B2J XML
> > > > >> parser and it seems like it will be feasible to make B2J use
> it all
> > > > >> over (B2J has turned out to be quite a thorough test of my
> XML parser
> > > > >> and thrown up a variety of bugs). It adds a total of 16.5K to
> > > the jar
> > > > >> (compressed) and would mean (i think) that the only
> requirement would
> > > > >> be for JSSE libraries, which I should be able to remove just
> by using
> > > > >> reflection and catching the ClassNotFoundException. These
> changes
> > > > >> (plus perhaps one or two other ones I expect I have missed)
> should
> > > > >> make B2J able to run with only 1.3 JVM libraries. Once
> thats done I
> > > > >> will try running on a Java ME JVM.
> > > > >>
> > > > >> thanks
> > > > >>
> > > > >> Antony
> > > > _______________________________________________
> > > > stp-newsgroup mailing list
> > > > stp-newsgroup@eclipse.org
> > > > https://dev.eclipse.org/mailman/listinfo/stp-newsgroup
> > > >
> > > _______________________________________________
> > > stp-newsgroup mailing list
> > > stp-newsgroup@eclipse.org
> > > https://dev.eclipse.org/mailman/listinfo/stp-newsgroup
> > >
> > _______________________________________________
> > stp-newsgroup mailing list
> > stp-newsgroup@eclipse.org
> > https://dev.eclipse.org/mailman/listinfo/stp-newsgroup
|
|
|
| Re: [stp-newsgroup] classes exclusion for runtime version [message #581007 is a reply to message #374030] |
Tue, 18 July 2006 10:28 |
Antony Miguel
Messages: 49
Registered: July 2009 |
Member |
|
|
Hi Keanu,
I've checked in some changes to B2J based on the changes we talk about
some time ago.
The latest B2J Core code in CVS now has no dependencies on a 1.4JVM and
you can use the build.xml to build a runtime only distribution.
I've tried this version on a 1.3 JVM and I've tried it on the J2ME JVMs
I mentioned before.
You can use the build.xml to build a runtime-only B2J.jar and then you
can use:
JVM_1.3\bin\java -cp b2j.jar
org.eclipse.stp.b2j.core.jengine.internal.mainengine.SoapDae mon
to run the distributed B2J engine daemon, then you can use the standard
Eclipse workbench to run a 'distributed' BPEL process on just that
target host or device.
To answer your previous questions:
I don't have any plans to integrate with any particular BPEL design
tools but I do plan to integrate with the STP deployment framework when
it is ready for integration.
The BPEL design tools I would imagine would just produce BPEL, so I
would see BPEL as the integration point there. I can imagine the BPEL
design tools and any deployment frameworks might want to integrate, and
then I would integrate B2J with the deployment frameworks.
I think the runtime build of the latest B2J code should satisfy the
requirements we talked about. It's no longer dependant on J2SE
libraries and there is no *live* code that is dependant on any UI
libraries etc when you are just running B2J as a runtime. As I said
above you should be able to just include the runtime built b2j.jar with
a 1.3 JVM and you should get no ClassDefNotFound errors.
Hopefully this puts B2J on the right track for you to be able to use it
but please let me know if there are any areas you have trouble with or
any other requirements you have.
thanks
Antony
YoungSang Paik wrote:
>
> Hi, Antony,
>
> > My wife and baby girl are fine and very happy thanks. Good luck with
> > August :)
> Thank you very much.
>
>
> > I think I see what you mean with the WSDL generation. You mean generate
> > the WSDL that describes the BPEL web service? I hadn't thought about
> > that to be honest. There are areas where the BPEL relies on the WSDL
> > for information like for binding information etc so you couldn't run the
> > BPEL without first having the WSDL for it, but you might be able to
> > generate basic WSDL for it which you could then fill in the missing
> > pieces? Is that what you had in mind?
> Right. Yeah, I am just asking you. I can handle this with manual work.
> So than's fine.
>
>
> > I should say that B2J isn't really aiming to provide any tooling for
> > creating the BPEL - that would be left to something like the
> > BPEL-designer project.
> Right. The rest of the stp project will be somehow related on this
> modeling projects.
> So, is there any integration plan you have with the modeling projects
> making visual diagram
> such as stp core framework, stp service creation, etc?
>
>
> >
> > The pluggable runtime and the ability of the runtime to run standalone
> > are not really tied to each other. The current B2J runtime is capable
> > of running standalone today and supports much of BPEL.
> >
> > The pluggability aspect is about making the B2J interfaces public so
> > that other Java runtimes may be written that use some of the same BPEL
> > to Java translation code. If you're happy with the capabilities of the
> > current runtime then you wouldn't need the pluggability aspect. If you
> > were planning on writing your own Java runtime that uses the BPEL to
> > Java translation then you would need it. Would you want to replace the
> > current runtime with your own runtime or do you just need the current
> > runtime to run standalone?
>
> Oh, I see. You are right. Standalone for now.
> In the future, 3-4 months later, I will need to extend the runtime to
> add some additional functionalities, though.
> In terms of pluggability, I mean what we have been discussed about.
> I suggested to you whether I can separate out the runtime module from
> the whole plugin - "org.eclipse.stp.b2j.core".
> Then you have made and published "runtime build" ant file to build
> runtime only version.
> However, it is just proof of concept level, so , for example, actual
> codes that depends on UI or debug are in the runtime-only jar.
> Also it has some dependency with j2se APIs - looking for xml in the java
> runtime.
>
>
> Thank you very much for your answer, again.
> Regards,
> Keanu
>
>
>
>
>
> >
> > thanks
> >
> > Antony
> >
> > YoungSang Paik wrote:
> > >
> > > Antony,
> > >
> > > Oh, I am very glad to hear that. How is your baby? How is your wife?
> > > I am also expecting a baby. Delivery date is expected to be August.
> > > Gonglatulations!
> > >
> > > For the WSDL, I mean the generation of WSDL that goes with BPEL. I
> mean
> > > the WSDL that BPEL represents.
> > >
> > > For the pluggable runtime (= runtime only version, I mean), I
> expect so
> > > because the concept actually coinsides with the b2j architecture.
> > > The concept : Runtime is pluggable so that the runtime only module can
> > > run standalone
> > >
> > > If it takes long time, it is sad to hear that.
> > > I hope it can be available soon.
> > >
> > > Thank you for your information.
> > > And conglatulation, again!
> > > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
> > > Paik, YoungSang (Keanu)
> > > Advanced Mobile Solution Technology Team in Ubiquitous Computing
> Lab (UCL)
> > > IBM, Korea
> > >
> > > Tel: (822)3781-7509, (8211)898-7509 Email: yspaik@kr.ibm.com
> > > Address : The MMAA Bldg 467-12 Dogok-dong. Gangnam-gu, Seoul, Korea
> > >
> > >
> > >
> > > *Antony Miguel <antony.miguel@scapatech.com>*
> > > Sent by: stp-newsgroup-bounces@eclipse.org
> > >
> > > 06/28/2006 10:33 PM
> > > Please respond to
> > > "Gateway between eclipse.stp and stp-newsgroup"
> <stp-newsgroup@eclipse.org>
> > >
> > >
> > >
> > > To
> > > stp-newsgroup@eclipse.org
> > > cc
> > >
> > > Subject
> > > Re: [stp-newsgroup] classes exclusion for runtime version
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Hi Keanu,
> > >
> > > Sorry for the extended delay in my response, I've been off from
> work for
> > > the past few weeks having a baby.
> > >
> > > To answer your questions:
> > >
> > > - I was not aware of the lack of a link to STP mailing lists, I'm not
> > > exactly sure where it would go but I'll speak to someone in STP
> about it
> > > and try to get it sorted.
> > >
> > > - B2J does not currently support generating Java SOAP clients from WSDL
> > > or generating WSDL from Java classes. B2J's Java binding is based on
> > > the Apache WSIF Java binding however so WSDL generated using wsif
> should
> > > work with B2J. In addition B2J does have both a SOAP server and SOAP
> > > client implementation but the SOAP client does not automatically
> > > translate anything based on WSDL - it only really deals with the SOAP
> > > envelope and HTTP etc.
> > >
> > > What exactly are you looking for in terms of client generation? If you
> > > expose a service with B2J then you naturally must have WSDL to describe
> > > it so I assume you are after something like a tool to generate a Java
> > > API (going via SOAP) to that service? Is that accurate? Something
> like
> > > this could potentially be implemented in B2J.
> > >
> > > - As far as the pluggable runtime. I intend to post a plan soon to the
> > > B2J website and newsgroups which will set out a roadmap for producing
> > > public APIs to fully integrate BPEL engines and servers into the B2J
> > > framework. As things stand, B2J provides good functionality but I do
> > > not believe that the current interfaces, if made public as APIs, would
> > > fit well with BPEL servers (basically there are assumptions in the B2J
> > > framework which are a result of the requirements of the BPEL engine,
> > > rather than a more general outlook of BPEL engines and servers).
> > >
> > > If you plan to use the B2J APIs to implement your own pluggable engine
> > > or server then your feedback and requirements would be extremely
> useful.
> > > I will try to advertise for feedback as widely as possible when I post
> > > the plan.
> > >
> > > I should also say that this plan will probably not be short term as I
> > > expect the process of creating and implementing the plan to take some
> > > time. I would be interested to hear what your timescales would be for
> > > using B2J also?
> > >
> > > thanks
> > >
> > > Antony
> > >
> > >
> > > YoungSang Paik wrote:
> > > >
> > > > Hi, Antony
> > > >
> > > > It's been a long time. How have you been?
> > > >
> > > >
> > > > I have a couple of questions.
> > > > - I wonder stp mailing list link is not shown on the eclipse web
> site.
> > > > Do you know that?
> > > > - Can I make a SOAP client for the service that BPEL script is
> exposing?
> > > > I mean, can b2j engine create WSDL just as Axis can generate
> WSDL for a
> > > > particular service so that SOAP client can be generated
> according to the
> > > > WSDL?
> > > > - Could I share any news for your pluggable b2j runtime?
> > > >
> > > > *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
> > > > Paik, YoungSang (Keanu)
> > > > Advanced Mobile Solution Technology Team in Ubiquitous Computing
> Lab
> > > (UCL)
> > > > IBM, Korea
> > > >
> > > > Tel: (822)3781-7509, (8211)898-7509 Email: yspaik@kr.ibm.com
> > > > Address : The MMAA Bldg 467-12 Dogok-dong. Gangnam-gu, Seoul, Korea
> > > >
> > > >
> > > >
> > > > *Antony Miguel <antony.miguel@scapatech.com>*
> > > > Sent by: stp-newsgroup-bounces@eclipse.org
> > > >
> > > > 05/16/2006 02:24 AM
> > > > Please respond to
> > > > "Gateway between eclipse.stp and stp-newsgroup"
> > > <stp-newsgroup@eclipse.org>
> > > >
> > > >
> > > >
> > > > To
> > > > stp-newsgroup@eclipse.org
> > > > cc
> > > >
> > > > Subject
> > > > Re: [stp-newsgroup] classes exclusion for runtime
> > > version
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Hi Keanu,
> > > >
> > > > I've written one test class that generates an engine program and
> saves
> > > > it to disk, and another test class that uses just the local
> engine to
> > > > run the compiled program (these would represent your client side
> BPEL
> > > > compilation step and your embedded device BPEL execution step).
> > > >
> > > > I've used these test classes to chop out bits of unused code
> from the
> > > > runtime only JAR including the distributed engine and make sure the
> > > > runtime only test program can still run BPEL using only the
> cut-down JAR.
> > > >
> > > > The resulting runtime only JAR which is still able to run the
> > > > precompiled BPEL files I mentioned below (test_xpath,
> test_messaging,
> > > > test_soapserver_pick) is 304KB. This should need no extra
> libraries to
> > > > run on CDC/FP 1.0 or Java 1.3.
> > > >
> > > > cheers
> > > >
> > > > Antony
> > > >
> > > > Antony Miguel wrote:
> > > > > Hi Keanu,
> > > > >
> > > > > I have converted B2J to use it's own XML parser, got the HTTP
> > > > > implementation to load JSSE via reflection and removed all
> 1.4 JVM
> > > > > library dependencies from B2J core (there were a few odd extra
> > > > > references such as java.net.URI).
> > > > >
> > > > > The end result is that the whole of B2J core (including the
> > > compilation
> > > > > stages - given that javac or some other compiler is present) can
> > > now run
> > > > > using:
> > > > >
> > > > > - IBM WEME 6.1 lnx-x86-ppro10 (which I believe is CDC/FP 1.0?)
> > > > > - Sun CVM CDC/FP 1.1
> > > > >
> > > > > Given that it runs on the above IBM WEME JVM it should also
> run OK on
> > > > > Sun CVM CDC/FP 1.0 but I haven't been able to build that JVM yet.
> > > > >
> > > > > I've been able to run almost all of the example BPEL files. In
> > > > > particular on both JVMs I have successfully run
> > > > >
> > > > > - test_xpath.bpel
> > > > > - test_soapserver_pick.bpel
> > > > > - test_messaging.bpel
> > > > >
> > > > > I think these constitute a reasonable all-round test. They
> > > include use
> > > > > of HTTP/SOAP, XPATH and heavy threading and synchronisation.
> > > > >
> > > > > Including the new XML parser and all changes the full core JAR
> > > stands at
> > > > > about 745KB. The runtime only JAR stands at 442KB (but this
> still
> > > > > includes the distributed engine).
> > > > >
> > > > > I plan to do some more thorough testing as one or two of the
> example
> > > > > files fail (for reasons which may or may be related to recent
> changes)
> > > > > but I don't see any real reason why these changes couldn't go
> into the
> > > > > B2J main stream. They don't in any way degrade the
> performance of B2J
> > > > > and they make it more flexible in it's requirements.
> > > > >
> > > > > Are these the right JVMs and CDC/FP specifications you were
> hoping
> > > for?
> > > > >
> > > > > thanks
> > > > >
> > > > > Antony
> > > > >
> > > > > Antony Miguel wrote:
> > > > >
> > > > >> Hi Keanu,
> > > > >>
> > > > >>>> This may not work in other JVMs, I think in my previous
> experience
> > > > >>>> it might break in an IBM JVM but I'm not sure.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> Oh, Really? For me, b2j still works fine with IBM sdk v 1.4.
> > > > >>> my version is
> > > > >>> - java fullversion "J2RE 1.4.2 IBM Windows 32 build
> cn142-20050609
> > > > >>
> > > > >>
> > > > >>
> > > > >> This was just me remembering an issue from a long time ago.
> I think
> > > > >> that once upon a time I saw some very subtle difference to
> do with
> > > > >> classloading but like I say I can't remember exactly what the
> > > deal was
> > > > >> (it was complicated). It occurred to me that if you were having
> > > > >> NoClassDefErrors thrown then it could be this issue again
> but if it
> > > > >> works fine for you on an IBM JVM then I expect it was a
> different
> > > issue.
> > > > >>
> > > > >>> Only exception I have noticed in b2j is java.io.EOFException
> > > with the
> > > > >>> test bpel script when I tested with distributed engines.
> (It is a
> > > > >>> endurable bug for now. I know b2j is still developing
> phase.) But I
> > > > >>> have not noticed any "error" messages from VM, not the
> exception
> > > > >>> messages from program, during the test run.
> > > > >>
> > > > >>
> > > > >>
> > > > >> That's not so good. Can you tell me what script it is
> thatfails and
> > > > >> email me the EOFException stacktrace please?
> > > > >>
> > > > >> Does it only occur with the distributed engine?
> > > > >>
> > > > >>> Oh, I see. Yes, I am temporarily doing with the full B2J
> jar on a
> > > > >>> common PC. I am transitting from design phase to
> development phase.
> > > > >>> Feasibility is the main activity. Right. Sure, I will wait.
> > > > >>> I really appreciate you effort.
> > > > >>
> > > > >>
> > > > >>
> > > > >> No problem, I am making progress with the conversion to the
> B2J XML
> > > > >> parser and it seems like it will be feasible to make B2J use
> it all
> > > > >> over (B2J has turned out to be quite a thorough test of my
> XML parser
> > > > >> and thrown up a variety of bugs). It adds a total of 16.5K to
> > > the jar
> > > > >> (compressed) and would mean (i think) that the only
> requirement would
> > > > >> be for JSSE libraries, which I should be able to remove just
> by using
> > > > >> reflection and catching the ClassNotFoundException. These
> changes
> > > > >> (plus perhaps one or two other ones I expect I have missed)
> should
> > > > >> make B2J able to run with only 1.3 JVM libraries. Once
> thats done I
> > > > >> will try running on a Java ME JVM.
> > > > >>
> > > > >> thanks
> > > > >>
> > > > >> Antony
> > > > _______________________________________________
> > > > stp-newsgroup mailing list
> > > > stp-newsgroup@eclipse.org
> > > > https://dev.eclipse.org/mailman/listinfo/stp-newsgroup
> > > >
> > > _______________________________________________
> > > stp-newsgroup mailing list
> > > stp-newsgroup@eclipse.org
> > > https://dev.eclipse.org/mailman/listinfo/stp-newsgroup
> > >
> > _______________________________________________
> > stp-newsgroup mailing list
> > stp-newsgroup@eclipse.org
> > https://dev.eclipse.org/mailman/listinfo/stp-newsgroup
|
|
|
Goto Forum:
Current Time: Fri Apr 19 05:08:57 GMT 2024
Powered by FUDForum. Page generated in 0.02329 seconds |
] 
Search
Help
Register
Login
Home
