How do you compile the client code if the home/remote exists only
in the VM of the running server?
Aaron
On Mon, 12 Nov 2001, marc fleury wrote:
I know there are many tools out there that do almost what I am going to
describe already, it is an improvement on x-doclet.
I am
: [JBoss-dev] [research] a home/remote generator
|
|
| How do you compile the client code if the home/remote exists only
|in the VM of the running server?
|
|Aaron
|
|On Mon, 12 Nov 2001, marc fleury wrote:
| I know there are many tools out there that do almost what I am going to
| describe already
What about client code that needs to use those interfaces? Which may be in
the same project or required by another?
Can't a developer write a HelloBean impl with a few xdoclet tags (cut and
pasted from an example) and have a working bean?
--jason
On Mon, 12 Nov 2001, marc fleury wrote:
I
marc fleury wrote:
well the point is more for webservices and the additional invokers.
Axis does this, in a clumsy way.
What would this technique bring you that XDoclet does not?
/Rickard
--
Rickard Öberg
___
Jboss-development mailing list
|What about client code that needs to use those interfaces? Which
For EJB client:
at deployment it is ok.
at compilation he needs the classes (aaron's point)
You still save the bean empty implementation (ejbPassivate etc), jar
generation, xml generation
For webservices client:
You save
by the
EasyEJBHelper. MyDumyClass is the bean implementation that is dropped in
/deploy for example.
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Aaron Mulder
Envoye : lundi, 12 novembre 2001 18:17
A : jBoss Developer
Objet : Re: [JBoss-dev] [research
a one stop shop
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|Rickard Oberg
|Sent: Monday, November 12, 2001 12:39 PM
|To: jBoss Developer
|Subject: Re: [JBoss-dev] [research] a home/remote generator
|
|
|marc fleury wrote:
|
| well
Once the classes are generated (written to file) they can be included in
client code ? ... or did I miss something here ? ...
The Together IDE as a ex. hides/Autogenerates from the implementation Bean
code ... since it is only stubs ! ...
/peter_f
on 1-11-12 18.16, Aaron Mulder at [EMAIL
Sacha Labourey wrote:
Just an idea...
Why not providing a helper class that would build smart proxies.
The client code is implemented like if it was acting against the source
class but it would need to use the helper factory to create the bean instead
of using the new operator. The
Hello Rickard,
Yes I know what you mean, I even read your book when it just came out... So
I certainly cannot be a bad boy ;)
My goal was just to follow the basic intended scheme: EJB access in 10
seconds.
My goal was certainly not to start a fight should remote methods raise a
subclass of
) hmm
hmm
hm
interesting.
marcf
|
|
|
| -Message d'origine-
| De : [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED]]De la part de
| Aaron Mulder
| Envoye : lundi, 12 novembre 2001 18:17
| A : jBoss Developer
| Objet : Re: [JBoss-dev] [research] a home/remote generator
FWIW, Bluestone did this. I tried to get them to stop.
Aaron Mulder wrote:
How do you compile the client code if the home/remote exists only
in the VM of the running server?
Aaron
On Mon, 12 Nov 2001, marc fleury wrote:
I know there are many tools out there that do almost what
system on this solution, but I
am sure this tool would reach its audience.
-Message d'origine-
De : marc fleury [mailto:[EMAIL PROTECTED]]
Envoye : lundi, 12 novembre 2001 19:03
A : Sacha Labourey; Aaron Mulder; jBoss Developer
Objet : RE: [JBoss-dev] [research] a home/remote generator
Developer
|Subject: RE: [JBoss-dev] [research] a home/remote generator
|
|
|Hello Rickard,
|
|Yes I know what you mean, I even read your book when it just came out... So
|I certainly cannot be a bad boy ;)
|
|My goal was just to follow the basic intended scheme: EJB access in 10
|seconds.
|
|My
Mulder
| | Envoye : lundi, 12 novembre 2001 18:17
| | A : jBoss Developer
| | Objet : Re: [JBoss-dev] [research] a home/remote generator
| |
| |
| | How do you compile the client code if the home/remote exists only
| | in the VM of the running server?
| |
| | Aaron
| |
| | On Mon, 12 Nov 2001, marc
Sacha Labourey wrote:
Yes, but one of the important point (I think) is that *the developer is able
to write the client code directly by referencing the bean code without
waiting for a code generator to generate the home and remote. The developer
modifies the bean? no problem, he can directly
Developer
Objet : RE: [JBoss-dev] [research] a home/remote generator
|I would certainly not build a online banking system on this
solution, but I
|am sure this tool would reach its audience.
even integrating my previous serious breaking of ejb contract (say the
finders/create) it is a point
marc fleury wrote:
If I get webservices in 10 seconds, I think we are in a very SWEET position,
we don't want to know about the EJB packaging and home and remote and
blablabla, screw all that, I DON'T CARE. We just drop the *CLASS* in the
deploy directory and voila! webservice for you sir!
|It is very similar to GLUE
|(http://www.themindelectric.com/products/glue/glue.html).
there you go, let's do it then...
marcf
|
|/Rickard
|
|--
|Rickard Öberg
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
On Mon, 12 Nov 2001, marc fleury wrote:
|It is very similar to GLUE
|(http://www.themindelectric.com/products/glue/glue.html).
there you go, let's do it then...
the problem with glue is we can't distribute the lib with jboss
it will require each user to go and download it individually
--
|the problem with glue is we can't distribute the lib with jboss
|it will require each user to go and download it individually
ok let's stop this, who said we wanted to distribute the libraries from
glue?
I was talking about doing similar functionality
marcf
|
|-- Juha
|
|
I've used GLUE and I think that they do it right. They make web services
seem like if it was just RMI.
Regards,
Hiram
From: Rickard Oberg [EMAIL PROTECTED]
To: jBoss Developer [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] [research] a home/remote generator
Date: Mon, 12 Nov 2001 19:28:57 +0100
On Mon, 12 Nov 2001, marc fleury wrote:
|the problem with glue is we can't distribute the lib with jboss
|it will require each user to go and download it individually
ok let's stop this, who said we wanted to distribute the libraries from
glue?
I would want to, cause its a very good lib.
yOn Mon, 12 Nov 2001, marc fleury wrote:
|It is very similar to GLUE
|(http://www.themindelectric.com/products/glue/glue.html).
there you go, let's do it then...
marcf
A coworker just brought up a good point. If we do this, we suddenly become
incompatible with other J2EE providers(I do
Adam Heath wrote:
A coworker just brought up a good point. If we do this, we suddenly become
incompatible with other J2EE providers
True, if you deploy on JBoss using this technique your project will be
unportable.
(I do know we don't have to make _stub
objects, which is already an
|A coworker just brought up a good point. If we do this, we suddenly become
|incompatible with other J2EE providers(I do know we don't have to
no we don't
marcf
|make _stub
|objects, which is already an incompatiblity).
|
|Is this something that s/b considered?
|
On 2001.11.12 14:05:03 -0500 Juha-P Lindfors wrote:
On Mon, 12 Nov 2001, marc fleury wrote:
|It is very similar to GLUE
|(http://www.themindelectric.com/products/glue/glue.html).
there you go, let's do it then...
the problem with glue is we can't distribute the lib with jboss
marc fleury wrote:
| A coworker just brought up a good point. If we do this, we
|suddenly become
| incompatible with other J2EE providers
|
|
|True, if you deploy on JBoss using this technique your project will be
|unportable.
wtf are you talking about? we don't break the jar format,
| A coworker just brought up a good point. If we do this, we
|suddenly become
| incompatible with other J2EE providers
|
|
|True, if you deploy on JBoss using this technique your project will be
|unportable.
wtf are you talking about? we don't break the jar format, if you give us a
jar we still
|Likewise. If JBoss is generating remote/home interfaces at runtime, then
|you won't be able to use these beans as you would other beans, i.e.
|you'd use properietary ways of accessing them that would break when you
|try to use the same beans in another container.
not in webservices approach, no
yOn Mon, 12 Nov 2001, marc fleury wrote:
|A coworker just brought up a good point. If we do this, we suddenly become
|incompatible with other J2EE providers(I do know we don't have to
no we don't
Yes, we do. Something developed for jboss will not run on other providers.
|Yes, we do. Something developed for jboss will not run on other providers.
No offense to your co-worker and Rickard but it is a dumb rhetoric point :)
If we offer this feature we do not break the compatibility of the J2EE
platform specification.
The spec doesn't specify portability in
yOn Mon, 12 Nov 2001, marc fleury wrote:
|A coworker just brought up a good point. If we do this, we suddenly
become
|incompatible with other J2EE providers(I do know we don't have to
no we don't
Yes, we do. Something developed for jboss will not run on other
providers.
Yes and No.
marc fleury wrote:
|Yes, we do. Something developed for jboss will not run on other providers.
No offense to your co-worker and Rickard but it is a dumb rhetoric point :)
If we offer this feature we do not break the compatibility of the J2EE
platform specification.
The spec doesn't
34 matches
Mail list logo
