[JBoss-dev] [research] a home/remote generator
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 wondering if the generation step cannot be done at deployment time. I
think we have the bytecode generation tools stuff that generates compiled
bytecode at runtime. See the 1.2.2 proxy generation and the implementation
Dain has put of the 2.0 spec CMP stuff. I will call them bytecode
injectors.
I would like the developer to just provide the implementation class with
HelloBean, bean identifying the implementation. The code would be
public class HelloBean extends SessionBean {
public String sayHello
{ return hi;}
}
}
and that is it. We would generate the home and remote with our code
injectors, if we find overridden methods (ejbActivate) then we would use
that from the class definition itself, if not we provide an empty
implementation. We put all the public methods in the Remote, minus the
create(...) and find...(...) that need manipulation in the home. Since we
control the classes definition that are loaded in our system we would be
able to plug this one in, the HelloBean implemented by us (actually it
could be under a different name since we are on the server side), and the
client sees the generated Hello (naming convention we remove the bean)
and HelloHome. This way the client can see the classes with the remote
loading.
For more advanced tags like the transactional ones we should incorporate
some x-doclet tags in the code, but these do not result in the xml file
generation and the jar creation rather it all works in JBoss, i.e. the
metadata population is done directly from the code. In essence we say fuck
packaging, too complex.
The goal there is really simple, it is to have the developers write the
trivial HelloBean above and BE DONE WITH THE EJB LEARNING CURVE.
marcf
Marc Fleury
President
JBoss Group, LLC
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
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 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 wondering if the generation step cannot be done at deployment time. I
think we have the bytecode generation tools stuff that generates compiled
bytecode at runtime. See the 1.2.2 proxy generation and the implementation
Dain has put of the 2.0 spec CMP stuff. I will call them bytecode
injectors.
I would like the developer to just provide the implementation class with
HelloBean, bean identifying the implementation. The code would be
public class HelloBean extends SessionBean {
public String sayHello
{ return hi;}
}
}
and that is it. We would generate the home and remote with our code
injectors, if we find overridden methods (ejbActivate) then we would use
that from the class definition itself, if not we provide an empty
implementation. We put all the public methods in the Remote, minus the
create(...) and find...(...) that need manipulation in the home. Since we
control the classes definition that are loaded in our system we would be
able to plug this one in, the HelloBean implemented by us (actually it
could be under a different name since we are on the server side), and the
client sees the generated Hello (naming convention we remove the bean)
and HelloHome. This way the client can see the classes with the remote
loading.
For more advanced tags like the transactional ones we should incorporate
some x-doclet tags in the code, but these do not result in the xml file
generation and the jar creation rather it all works in JBoss, i.e. the
metadata population is done directly from the code. In essence we say fuck
packaging, too complex.
The goal there is really simple, it is to have the developers write the
trivial HelloBean above and BE DONE WITH THE EJB LEARNING CURVE.
marcf
Marc Fleury
President
JBoss Group, LLC
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
well the point is more for webservices and the additional invokers.
Axis does this, in a clumsy way.
marcf
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Aaron
|Mulder
|Sent: Monday, November 12, 2001 12:17 PM
|To: jBoss Developer
|Subject: 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 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 wondering if the generation step cannot be done at
|deployment time. I
| think we have the bytecode generation tools stuff that generates compiled
| bytecode at runtime. See the 1.2.2 proxy generation and the
|implementation
| Dain has put of the 2.0 spec CMP stuff. I will call them bytecode
| injectors.
|
| I would like the developer to just provide the implementation
|class with
| HelloBean, bean identifying the implementation. The code would be
|
| public class HelloBean extends SessionBean {
|
| public String sayHello
| { return hi;}
| }
| }
|
| and that is it. We would generate the home and remote with our code
| injectors, if we find overridden methods (ejbActivate) then we would use
| that from the class definition itself, if not we provide an empty
| implementation. We put all the public methods in the Remote, minus the
| create(...) and find...(...) that need manipulation in the home. Since we
| control the classes definition that are loaded in our system we would be
| able to plug this one in, the HelloBean implemented by us (actually it
| could be under a different name since we are on the server side), and the
| client sees the generated Hello (naming convention we remove
|the bean)
| and HelloHome. This way the client can see the classes with the remote
| loading.
|
| For more advanced tags like the transactional ones we should incorporate
| some x-doclet tags in the code, but these do not result in the xml file
| generation and the jar creation rather it all works in JBoss, i.e. the
| metadata population is done directly from the code. In essence
|we say fuck
| packaging, too complex.
|
| The goal there is really simple, it is to have the developers write the
| trivial HelloBean above and BE DONE WITH THE EJB LEARNING CURVE.
|
| marcf
|
|
| Marc Fleury
| President
| JBoss Group, LLC
|
|
|
| ___
| Jboss-development mailing list
| [EMAIL PROTECTED]
| https://lists.sourceforge.net/lists/listinfo/jboss-development
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [research] a home/remote generator
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 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 wondering if the generation step cannot be done at deployment time. I
think we have the bytecode generation tools stuff that generates compiled
bytecode at runtime. See the 1.2.2 proxy generation and the implementation
Dain has put of the 2.0 spec CMP stuff. I will call them bytecode
injectors.
I would like the developer to just provide the implementation class with
HelloBean, bean identifying the implementation. The code would be
public class HelloBean extends SessionBean {
public String sayHello
{ return hi;}
}
}
and that is it. We would generate the home and remote with our code
injectors, if we find overridden methods (ejbActivate) then we would use
that from the class definition itself, if not we provide an empty
implementation. We put all the public methods in the Remote, minus the
create(...) and find...(...) that need manipulation in the home. Since we
control the classes definition that are loaded in our system we would be
able to plug this one in, the HelloBean implemented by us (actually it
could be under a different name since we are on the server side), and the
client sees the generated Hello (naming convention we remove the bean)
and HelloHome. This way the client can see the classes with the remote
loading.
For more advanced tags like the transactional ones we should incorporate
some x-doclet tags in the code, but these do not result in the xml file
generation and the jar creation rather it all works in JBoss, i.e. the
metadata population is done directly from the code. In essence we say fuck
packaging, too complex.
The goal there is really simple, it is to have the developers write the
trivial HelloBean above and BE DONE WITH THE EJB LEARNING CURVE.
marcf
Marc Fleury
President
JBoss Group, LLC
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [research] a home/remote generator
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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
|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 everything, generate the wsdl and uddi entry (like in axis really)
and you are done. Your webservice is backed by the simplest of all and it
is an EJB which makes it a powerful implementation.
|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?
I want to integrate these features in the standard JBoss, it needs to be
baby food for the guys who come.
marcf
|
|--jason
|
|
|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 wondering if the generation step cannot be done at
|deployment time. I
| think we have the bytecode generation tools stuff that generates compiled
| bytecode at runtime. See the 1.2.2 proxy generation and the
|implementation
| Dain has put of the 2.0 spec CMP stuff. I will call them bytecode
| injectors.
|
| I would like the developer to just provide the implementation
|class with
| HelloBean, bean identifying the implementation. The code would be
|
| public class HelloBean extends SessionBean {
|
| public String sayHello
| { return hi;}
| }
| }
|
| and that is it. We would generate the home and remote with our code
| injectors, if we find overridden methods (ejbActivate) then we would use
| that from the class definition itself, if not we provide an empty
| implementation. We put all the public methods in the Remote, minus the
| create(...) and find...(...) that need manipulation in the home. Since we
| control the classes definition that are loaded in our system we would be
| able to plug this one in, the HelloBean implemented by us (actually it
| could be under a different name since we are on the server side), and the
| client sees the generated Hello (naming convention we remove
|the bean)
| and HelloHome. This way the client can see the classes with the remote
| loading.
|
| For more advanced tags like the transactional ones we should incorporate
| some x-doclet tags in the code, but these do not result in the xml file
| generation and the jar creation rather it all works in JBoss, i.e. the
| metadata population is done directly from the code. In essence
|we say fuck
| packaging, too complex.
|
| The goal there is really simple, it is to have the developers write the
| trivial HelloBean above and BE DONE WITH THE EJB LEARNING CURVE.
|
| marcf
|
|
| Marc Fleury
| President
| JBoss Group, LLC
|
|
|
| ___
| Jboss-development mailing list
| [EMAIL PROTECTED]
| https://lists.sourceforge.net/lists/listinfo/jboss-development
|
|
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
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 helper factory would access JNDI, get the
home, get the remote a forward the requests, masking the RemoteException.
i.e.
MyDumyClass myObj = (MyDumyClass)EasyEJBHelper.createInstance
(MyDumyClass.class);
myObj.doThis ();
myObj.doThat ();
So we would wrap the server proxy in a client proxy built 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 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, it is an improvement on x-doclet.
I am wondering if the generation step cannot be done at
deployment time. I
think we have the bytecode generation tools stuff that
generates compiled
bytecode at runtime. See the 1.2.2 proxy generation and the
implementation
Dain has put of the 2.0 spec CMP stuff. I will call them bytecode
injectors.
I would like the developer to just provide the implementation
class with
HelloBean, bean identifying the implementation. The code would be
public class HelloBean extends SessionBean {
public String sayHello
{ return hi;}
}
}
and that is it. We would generate the home and remote with our code
injectors, if we find overridden methods (ejbActivate) then we
would use
that from the class definition itself, if not we provide an empty
implementation. We put all the public methods in the Remote, minus the
create(...) and find...(...) that need manipulation in the
home. Since we
control the classes definition that are loaded in our system we would be
able to plug this one in, the HelloBean implemented by us (actually it
could be under a different name since we are on the server
side), and the
client sees the generated Hello (naming convention we remove
the bean)
and HelloHome. This way the client can see the classes with
the remote
loading.
For more advanced tags like the transactional ones we should incorporate
some x-doclet tags in the code, but these do not result in the xml file
generation and the jar creation rather it all works in JBoss, i.e. the
metadata population is done directly from the code. In essence
we say fuck
packaging, too complex.
The goal there is really simple, it is to have the developers write the
trivial HelloBean above and BE DONE WITH THE EJB LEARNING CURVE.
marcf
Marc Fleury
President
JBoss Group, LLC
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
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 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 |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [research] a home/remote generator
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 PROTECTED] 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 I am going to
describe already, it is an improvement on x-doclet.
I am wondering if the generation step cannot be done at deployment time. I
think we have the bytecode generation tools stuff that generates compiled
bytecode at runtime. See the 1.2.2 proxy generation and the implementation
Dain has put of the 2.0 spec CMP stuff. I will call them bytecode
injectors.
I would like the developer to just provide the implementation class with
HelloBean, bean identifying the implementation. The code would be
public class HelloBean extends SessionBean {
public String sayHello
{ return hi;}
}
}
and that is it. We would generate the home and remote with our code
injectors, if we find overridden methods (ejbActivate) then we would use
that from the class definition itself, if not we provide an empty
implementation. We put all the public methods in the Remote, minus the
create(...) and find...(...) that need manipulation in the home. Since we
control the classes definition that are loaded in our system we would be
able to plug this one in, the HelloBean implemented by us (actually it
could be under a different name since we are on the server side), and the
client sees the generated Hello (naming convention we remove the bean)
and HelloHome. This way the client can see the classes with the remote
loading.
For more advanced tags like the transactional ones we should incorporate
some x-doclet tags in the code, but these do not result in the xml file
generation and the jar creation rather it all works in JBoss, i.e. the
metadata population is done directly from the code. In essence we say fuck
packaging, too complex.
The goal there is really simple, it is to have the developers write the
trivial HelloBean above and BE DONE WITH THE EJB LEARNING CURVE.
marcf
Marc Fleury
President
JBoss Group, LLC
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [research] a home/remote generator
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 helper factory would access JNDI, get the home, get the remote a forward the requests, masking the RemoteException. i.e. MyDumyClass myObj = (MyDumyClass)EasyEJBHelper.createInstance (MyDumyClass.class); myObj.doThis (); myObj.doThat (); So we would wrap the server proxy in a client proxy built by the EasyEJBHelper. MyDumyClass is the bean implementation that is dropped in /deploy for example. If the RMI team heard you they would kill you ;-) /Rickard ps. Refer to the notes on distributed computing by Waldo et. al for details -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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 goal was certainly not to start a fight should remote methods raise a subclass of java.lang.Exception or java.lang.Error... ;) Cheers, Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de .. If the RMI team heard you they would kill you ;-) /Rickard ps. Refer to the notes on distributed computing by Waldo et. al for details ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
|Just an idea...
Your $20 worth ...
:)
|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 helper factory would access JNDI, get the
|home, get the remote a forward the requests, masking the RemoteException.
|i.e.
|
|
| MyDumyClass myObj = (MyDumyClass)EasyEJBHelper.createInstance
|(MyDumyClass.class);
|
| myObj.doThis ();
| myObj.doThat ();
|
|So we would wrap the server proxy in a client proxy built by the
|EasyEJBHelper. MyDumyClass is the bean implementation that is dropped in
|/deploy for example.
Let me get this right. You want the client to operate on the bean directly
through the methods, but still buy the indirection on the EJB transaction
and security. The JavaBeans pattern for that would be pretty cool in fact.
The pattern is know as the access bean. You are proposing that the access
bean exposes the *BEAN* interface even though behind the covers it is an EJB
that does the transactional/security integration + additional plugin
services (e.g. CMP) 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
|
|
| 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 wondering if the generation step cannot be done at
| deployment time. I
| think we have the bytecode generation tools stuff that
| generates compiled
| bytecode at runtime. See the 1.2.2 proxy generation and the
| implementation
| Dain has put of the 2.0 spec CMP stuff. I will call them bytecode
| injectors.
|
| I would like the developer to just provide the implementation
| class with
| HelloBean, bean identifying the implementation. The code would be
|
| public class HelloBean extends SessionBean {
|
| public String sayHello
| { return hi;}
| }
| }
|
| and that is it. We would generate the home and remote with our code
| injectors, if we find overridden methods (ejbActivate) then we
| would use
| that from the class definition itself, if not we provide an empty
| implementation. We put all the public methods in the Remote, minus the
| create(...) and find...(...) that need manipulation in the
| home. Since we
| control the classes definition that are loaded in our system
|we would be
| able to plug this one in, the HelloBean implemented by us
|(actually it
| could be under a different name since we are on the server
| side), and the
| client sees the generated Hello (naming convention we remove
| the bean)
| and HelloHome. This way the client can see the classes with
| the remote
| loading.
|
| For more advanced tags like the transactional ones we should
|incorporate
| some x-doclet tags in the code, but these do not result in the xml file
| generation and the jar creation rather it all works in JBoss, i.e. the
| metadata population is done directly from the code. In essence
| we say fuck
| packaging, too complex.
|
| The goal there is really simple, it is to have the developers write the
| trivial HelloBean above and BE DONE WITH THE EJB LEARNING CURVE.
|
| marcf
|
|
| Marc Fleury
| President
| JBoss Group, LLC
|
|
|
| ___
| Jboss-development mailing list
| [EMAIL PROTECTED]
| https://lists.sourceforge.net/lists/listinfo/jboss-development
|
|
|
| ___
| Jboss-development mailing list
| [EMAIL PROTECTED]
| https://lists.sourceforge.net/lists/listinfo/jboss-development
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
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 I am going to
describe already, it is an improvement on x-doclet.
I am wondering if the generation step cannot be done at deployment time. I
think we have the bytecode generation tools stuff that generates compiled
bytecode at runtime. See the 1.2.2 proxy generation and the implementation
Dain has put of the 2.0 spec CMP stuff. I will call them bytecode
injectors.
I would like the developer to just provide the implementation class with
HelloBean, bean identifying the implementation. The code would be
public class HelloBean extends SessionBean {
public String sayHello
{ return hi;}
}
}
and that is it. We would generate the home and remote with our code
injectors, if we find overridden methods (ejbActivate) then we would use
that from the class definition itself, if not we provide an empty
implementation. We put all the public methods in the Remote, minus the
create(...) and find...(...) that need manipulation in the home. Since we
control the classes definition that are loaded in our system we would be
able to plug this one in, the HelloBean implemented by us (actually it
could be under a different name since we are on the server side), and the
client sees the generated Hello (naming convention we remove the bean)
and HelloHome. This way the client can see the classes with the remote
loading.
For more advanced tags like the transactional ones we should incorporate
some x-doclet tags in the code, but these do not result in the xml file
generation and the jar creation rather it all works in JBoss, i.e. the
metadata population is done directly from the code. In essence we say fuck
packaging, too complex.
The goal there is really simple, it is to have the developers write the
trivial HelloBean above and BE DONE WITH THE EJB LEARNING CURVE.
marcf
Marc Fleury
President
JBoss Group, LLC
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
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 uses the new methods in its
editor for the client code. The magic lies in the client proxy generated by
the factory.
The developer acts like if he was calling methods on the bean class (and
that is almost also what the compiler think) but at runtime, the factory get
a home+remote from JNDI and wraps the EJB proxy in its own proxy. And thus
calls are exectued on the EJB server (going through the interceptor chain).
Thus, you keep the ability to compile code directly, as you write the bean,
while keeping the execution on JBoss. Then you can use JNDI environment
variable on the client JVM to tell it where to lookup the JBoss server.
As for Rickard's RMI semantic concern, why not making the client proxy raise
java.lang.Error in case of problem (instead of java.lang.Exception). As it
seem that this has even been discussed by the RMI team HIMSELF, it should be
OK ;)
I would certainly not build a online banking 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
|Just an idea...
Your $20 worth ...
:)
|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 helper factory would access JNDI, get the
|home, get the remote a forward the requests, masking the RemoteException.
|i.e.
|
|
| MyDumyClass myObj = (MyDumyClass)EasyEJBHelper.createInstance
|(MyDumyClass.class);
|
| myObj.doThis ();
| myObj.doThat ();
|
|So we would wrap the server proxy in a client proxy built by the
|EasyEJBHelper. MyDumyClass is the bean implementation that is dropped in
|/deploy for example.
Let me get this right. You want the client to operate on the
bean directly
through the methods, but still buy the indirection on the EJB transaction
and security. The JavaBeans pattern for that would be pretty
cool in fact.
The pattern is know as the access bean. You are proposing that the access
bean exposes the *BEAN* interface even though behind the covers
it is an EJB
that does the transactional/security integration + additional plugin
services (e.g. CMP) 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
|
|
|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 wondering if the generation step cannot be done at
| deployment time. I
| think we have the bytecode generation tools stuff that
| generates compiled
| bytecode at runtime. See the 1.2.2 proxy generation and the
| implementation
| Dain has put of the 2.0 spec CMP stuff. I will call them bytecode
| injectors.
|
| I would like the developer to just provide the implementation
| class with
| HelloBean, bean identifying the implementation. The
code would be
|
| public class HelloBean extends SessionBean {
|
| public String sayHello
| { return hi;}
| }
| }
|
| and that is it. We would generate the home and remote with our code
| injectors, if we find overridden methods (ejbActivate) then we
| would use
| that from the class definition itself, if not we provide an empty
| implementation. We put all the public methods in the
Remote, minus the
| create(...) and find...(...) that need manipulation in the
| home. Since we
| control the classes definition that are loaded in our system
|we would be
| able to plug this one in, the HelloBean implemented by us
|(actually it
| could be under a different name since we are on the server
| side), and the
| client sees the generated Hello (naming convention we remove
| the bean)
| and HelloHome. This way the client can see the classes with
| the remote
| loading.
|
| For more advanced tags like the transactional ones we should
|incorporate
| some x-doclet tags in the code, but these do not result in
the xml file
| generation and the jar creation rather it all works in
JBoss, i.e. the
| metadata population is done
RE: [JBoss-dev] [research] a home/remote generator
actually the one problem I see with this is that we seriously break the client contract as the API of the bean is really not a match with the remote, think create. Again I think the advantage is on the server bean saving space and allowing for extremelly simple deployment of webservices. As a side note, for EJBs even, nothing prevents us from saving that bytecode generation to a jar, at deployment time so that you can compile (the problem raised by Aaron is only the compilation). 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! with an EJB backing it up, how fucking sweet is that? Again axis does part of this without the clean system behind it. It would be easy to integrate the transaction and security in there, by the x-doclet tags. whatever, will do when there is a moment marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha |Labourey |Sent: Monday, November 12, 2001 12:58 PM |To: Rickard Oberg; jBoss 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 goal was certainly not to start a fight should remote methods raise a |subclass of java.lang.Exception or java.lang.Error... ;) | |Cheers, | | | | Sacha | | -Message d'origine- | De : [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED]]De la part de |.. | | If the RMI team heard you they would kill you ;-) | | /Rickard | | ps. Refer to the notes on distributed computing by Waldo et. al for | details | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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, that it would reach its audience.
Again I would satisfied with the .net approach to it where the client side
doesn't suffer from this artificial (compilation bound) limitation.
marcf
|
| -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
|
|
| |Just an idea...
|
| Your $20 worth ...
|
| :)
|
| |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 helper factory would access JNDI, get the
| |home, get the remote a forward the requests, masking the
|RemoteException.
| |i.e.
| |
| |
| |MyDumyClass myObj = (MyDumyClass)EasyEJBHelper.createInstance
| |(MyDumyClass.class);
| |
| |myObj.doThis ();
| |myObj.doThat ();
| |
| |So we would wrap the server proxy in a client proxy built by the
| |EasyEJBHelper. MyDumyClass is the bean implementation that is dropped in
| |/deploy for example.
|
| Let me get this right. You want the client to operate on the
| bean directly
| through the methods, but still buy the indirection on the EJB transaction
| and security. The JavaBeans pattern for that would be pretty
| cool in fact.
| The pattern is know as the access bean. You are proposing that
|the access
| bean exposes the *BEAN* interface even though behind the covers
| it is an EJB
| that does the transactional/security integration + additional plugin
| services (e.g. CMP) 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
| |
| |
| | 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 wondering if the generation step cannot be done at
| | deployment time. I
| | think we have the bytecode generation tools stuff that
| | generates compiled
| | bytecode at runtime. See the 1.2.2 proxy generation and the
| | implementation
| | Dain has put of the 2.0 spec CMP stuff. I will call them bytecode
| | injectors.
| |
| | I would like the developer to just provide the implementation
| | class with
| | HelloBean, bean identifying the implementation. The
| code would be
| |
| | public class HelloBean extends SessionBean {
| |
| | public String sayHello
| | { return hi;}
| | }
| | }
| |
| | and that is it. We would generate the home and remote with our code
| | injectors, if we find overridden methods (ejbActivate) then we
| | would use
| | that from the class definition itself, if not we provide an empty
| | implementation. We put all the public methods in the
| Remote, minus the
| | create(...) and find...(...) that need manipulation in the
| | home. Since we
| | control the classes definition that are loaded in our system
| |we would be
| | able to plug this one in, the HelloBean implemented by us
| |(actually it
| | could be under a different name since we are on the server
| | side), and the
| | client sees the generated Hello (naming convention we remove
| | the bean)
| | and HelloHome. This way the client can see the classes with
| | the remote
| | loading.
| |
| | For more advanced tags like the transactional ones we should
| |incorporate
| | some x-doclet tags in the code, but these do not result in
| the xml file
| | generation and the jar creation rather it all works in
| JBoss, i.e. the
| | metadata population is done directly from the code. In essence
| | we say fuck
| | packaging, too complex.
| |
| | The goal there is really simple, it is to have the
| developers write the
| | trivial HelloBean above and BE DONE WITH THE EJB LEARNING CURVE.
| |
| | marcf
| |
| |
| | Marc Fleury
| | President
| | JBoss Group, LLC
| |
| |
| |
| | ___
| | Jboss-development mailing list
| | [EMAIL PROTECTED]
| | https://lists.sourceforge.net/lists/listinfo/jboss-development
| |
| |
| |
| | ___
| | Jboss-development mailing list
| | [EMAIL PROTECTED]
| | https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [research] a home/remote generator
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 uses the new methods in its editor for the client code. The magic lies in the client proxy generated by the factory. Sounds like Voyager to me (a RMI-ish mobile agent system). I.e. old news. As for Rickard's RMI semantic concern, why not making the client proxy raise java.lang.Error in case of problem (instead of java.lang.Exception). As it seem that this has even been discussed by the RMI team HIMSELF, it should be OK ;) Voyager used RuntimeExceptions, which is better. Still bad :-) I would certainly not build a online banking system on this solution, but I am sure this tool would reach its audience. IMHO the audience would be very limited. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
I am not sure I understand the create issue... Do you mean that with this kind of client, a SFSB would be, semantically, more appropriate? -Message d'origine- De : marc fleury [mailto:[EMAIL PROTECTED]] Envoye : lundi, 12 novembre 2001 19:23 A : Sacha Labourey; Aaron Mulder; jBoss 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, that it would reach its audience. Again I would satisfied with the .net approach to it where the client side doesn't suffer from this artificial (compilation bound) limitation. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [research] a home/remote generator
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! with an EJB backing it up, how fucking sweet is that? It is very similar to GLUE (http://www.themindelectric.com/products/glue/glue.html). /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
|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] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
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 -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
|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 | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [research] a home/remote generator
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 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! with an EJB backing it up, how fucking sweet is that? It is very similar to GLUE (http://www.themindelectric.com/products/glue/glue.html). /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
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. And free (beer). But can't distribute with an IDE or app server, which sucks :p anyway... how does AXIS do it differently... and why? -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
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 know we don't have to make _stub objects, which is already an incompatiblity). Is this something that s/b considered? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [research] a home/remote generator
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 incompatiblity). That does not affect portability, but is just an implementation detail. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
|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? | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [research] a home/remote generator
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 it will require each user to go and download it individually We could always ask-- the license hints at possible availability of other license terms. Their example app servers all cost money;-) david jencks -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [research] a home/remote generator
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, if you give us a jar we still support it, so something that works on J2EE works on our stuff. Get real! 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. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
| 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 support it, so something that works on J2EE works on our stuff. Get real! Where does the J2EE spec say that adding features on top of the spec breaks compatibility. If you want to go through the whole pain, you can. marcf | | (I do know we don't have to make _stub | objects, which is already an incompatiblity). | | |That does not affect portability, but is just an implementation detail. | |/Rickard | |-- |Rickard Öberg | | | |___ |Jboss-development mailing list |[EMAIL PROTECTED] |https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
|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 marcf | |/Rickard | |-- |Rickard Öberg | | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
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. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [research] a home/remote generator
|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 features it does not specify, if you know what I mean? It specifies portability in features that are defined and we don't break that. I mean it, Rickard you asleep yet? marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [research] a home/remote generator
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. Deployed applications are always vendor specific that is what deployment is for. This is according to the spec. Developer should be apple to develop an application which can be deployed on any compatible app. server. And this is possible with JBoss. Have fun - Andy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [research] a home/remote generator
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 specify portability in features it does not specify, if you know what I mean? It specifies portability in features that are defined and we don't break that. Just don't call it EJB. You're making it look EJB'ish. People will think it's EJB. But it's not. Hey, doesn't this remind everyone of J++? Sure, it's Java! Great! Oh, and we got these extensions that you can use that will make you a Poweruser. Very cool! Oh, can't run on other VM's? Well.. too bad.. I guess.. I mean it, Rickard you asleep yet? Me? No, I'm wide awake. You should consider pinching yourself tho ;-) If you want it to be EJB-ish, the best way to go about it is to join the EJB expert group, and lobby for these kinds of additions. /Rickard -- Rickard Öberg ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
