You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@apache.org> on 2002/04/01 23:28:55 UTC
[OT] Metadata inside the JVM bytecodes
http://jcp.org/jsr/detail/175.jsp
--
Cheers,
Pete
*---------------------------------------------------------*
| Programming today is a race between software engineers |
| striving to build bigger and better idiot-proof |
| programs,and the universe trying to produce bigger and |
| better idiots. So far, the universe is winning. |
| - Richard Cook |
*---------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Separation of Interface from Implementation visuals
Posted by Peter Donald <pe...@apache.org>.
On Sat, 6 Apr 2002 02:58, Pete Carapetyan wrote:
> Separation of Interface/Implementation
...
>
> http://couldbe.net/InterfaceImpl/
>
> Thanks for your help in sorting this out.
Looks great so far!
--
Cheers,
Pete
*--------------------------------------------------*
| Wise men don't need advice. Fools don't take it. |
| -Benjamin Franklin |
*--------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Separation of Interface from Implementation visuals
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Berin:
I have read through your note a couple times, just to make sure that I find any corrections that are necessary. Your explanations help. Thank you.
The only corrections I found, though, are in my use of the word interface where it is actually called a Role or Work Interface. I will make that correction, and wait for any other corrections that need to be made, in case others find errors.
Let me know if there is anything else below here that I missed.
Pete Carapetyan
Berin Loritsch wrote:
>
> > From: Pete Carapetyan [mailto:pete@datafundamentals.com]
> >
> > Separation of Interface/Implementation
> >
>
> After looking at your visuals, I do have some comments.
>
> Separation of Interface and Implementation is at the core of
> component oriented programming. You cannot have one without
> the other. Unfortunately, some people feel it necessary to
> confuse the issue by calling every standard API a component.
>
> The Avalon terminology for the interface is the "role". The
> role is the work interface, or the interface that you as a
> user of the component interact with. The reason we call it
> a role is to help when decomposing the system down into
> different components.
>
> One thing that you have to understand about component
> programming is that implementation != interface. Java has
> a keyword "interface" that we use to define our interfaces.
>
> In work interfaces (or roles), we define the minimum set
> of contracts that any implementor of the role must satisfy.
>
> The ever popular ObjectStore example will have a base interface:
>
> interface ObjectStore
> {
> void store(String key, Object store);
> Object retrieve(String key);
> Object remove(String key);
> }
>
> The minimum contracts this interface satisfies is that an
> object is stored with a client specified String key. The
> client can then either retrieve the object or remove it
> using the same key. When the client calls the "retrieve"
> method, the object remains in the Store, but when it calls
> the "remove" method the object is removed from the store.
>
> Notice that there is no meantion of wether or not the
> ObjectStore is persistent (i.e. data remains across JVM
> invocations).
>
> In order to satisfy that _guarantee_, we extend the interface
> like this:
>
> interface PersistentObjectStore extends Store
> {}
>
> They both have the same basic guarantees, but the new
> interface has the added contract that it must be persistent.
>
> Notice in neither of these cases, there is no mention of
> _where_ the components are stored. That is not important to
> the client. Configuring the components is a different
> concern.
>
> When you define interfaces, you must think of the *function*
> of the component. Sometimes it is better to have many smaller
> special purpose components than one large component that must
> change its interface each time a new contract is placed on it.
>
> To clarify the roles of the patterns used, look below:
>
> Separation of Interface and Implementation:
> basic definition of a component.
>
> Separation of Concerns:
> keep the management, use, and configuration interfaces separate.
> This simplifies the client's view of the component.
>
> Inversion of Control:
> how containers and components work together.
>
> If you need any more clarifications let me know.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Separation of Interface from Implementation visuals
Posted by Berin Loritsch <bl...@avalon.org>.
> From: Pete Carapetyan [mailto:pete@datafundamentals.com]
>
> Separation of Interface/Implementation
>
After looking at your visuals, I do have some comments.
Separation of Interface and Implementation is at the core of
component oriented programming. You cannot have one without
the other. Unfortunately, some people feel it necessary to
confuse the issue by calling every standard API a component.
The Avalon terminology for the interface is the "role". The
role is the work interface, or the interface that you as a
user of the component interact with. The reason we call it
a role is to help when decomposing the system down into
different components.
One thing that you have to understand about component
programming is that implementation != interface. Java has
a keyword "interface" that we use to define our interfaces.
In work interfaces (or roles), we define the minimum set
of contracts that any implementor of the role must satisfy.
The ever popular ObjectStore example will have a base interface:
interface ObjectStore
{
void store(String key, Object store);
Object retrieve(String key);
Object remove(String key);
}
The minimum contracts this interface satisfies is that an
object is stored with a client specified String key. The
client can then either retrieve the object or remove it
using the same key. When the client calls the "retrieve"
method, the object remains in the Store, but when it calls
the "remove" method the object is removed from the store.
Notice that there is no meantion of wether or not the
ObjectStore is persistent (i.e. data remains across JVM
invocations).
In order to satisfy that _guarantee_, we extend the interface
like this:
interface PersistentObjectStore extends Store
{}
They both have the same basic guarantees, but the new
interface has the added contract that it must be persistent.
Notice in neither of these cases, there is no mention of
_where_ the components are stored. That is not important to
the client. Configuring the components is a different
concern.
When you define interfaces, you must think of the *function*
of the component. Sometimes it is better to have many smaller
special purpose components than one large component that must
change its interface each time a new contract is placed on it.
To clarify the roles of the patterns used, look below:
Separation of Interface and Implementation:
basic definition of a component.
Separation of Concerns:
keep the management, use, and configuration interfaces separate.
This simplifies the client's view of the component.
Inversion of Control:
how containers and components work together.
If you need any more clarifications let me know.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Separation of Interface from Implementation visuals
Posted by Peter Donald <pe...@apache.org>.
On Sun, 7 Apr 2002 04:06, Pete Carapetyan wrote:
> A more specific fear, is those like myself, who think they understand it,
> but spend a couple weeks designing some new component to contribute that
> assumes a new "ROLE" or "Work Interface" which is not based on some a set
> of standard API's call signatures, but instead based on their own
> component.
That can be the case. I have a bunch of components that are not based on any
published interface or anything. It was just a useful abstraction layer for
me at the time. So I don't think this is a huuuge problem.
> So then the Paul, Leo, Peter, Berin and Federico have to either
> a.) break the guy's heart, or
> b.) tell him he has to re-write it so it works with JXXX and JYYY call
> signatures, and decouple his own, or c.) do it for him, or
> d.) just bring it in anyway.
> Not good choices. So how to let people know in advance and make sure that
> they really "got it." ?
To be honest I usually would do (d) and then suggest that it be reworked in
fashion X so that it can be more generic or whatever ;)
> The same is true with Separation of Concerns. Most of the actual work is in
> the code of the implementation, but most of the VALUE is in making the ROLE
> or Work Interface sensible enough for future pluggability. Again,
> everything hinges on that interface. And because the committers already
> understand this obvious fact so deeply, it never gets the emphasis in the
> otherwise excellent and very helpful documentation on the site. It is just
> kind of assumed that the reader will figure out how totally pivotal the
> call signature of the ROLE is to future pluggability.
thats probably the case ;)
Paul recently added some more documentation. Can you look at it and see what
needs doing. Also your documentation looked good - perhaps we could elaborate
on that and integrate it into the main site?
> The way I see it, Paul, Leo, Peter, Berin and Federico would publish in
> bold type a page for contributors that went like this: Want to contribute
> your Implementation or Component?
> 1. Design the interface per some very standard JBLAH or other API's
> 2. Submit the interface as a formal ROLE
> [stop, do not proceed beyond this point]
> 3. When approved, then and only then, write your component.
> 4. If you have non-standard public calls that your component requires, that
> is fine, but they need to be made in a separate ROLE so as not to pimp the
> rest of us who don't want to make them. 5. Submit your component.
>
> This would allow lesser brained individuals such as myself, a "See Dick
> Run" level of guidance. A simple roadmap to follow, as even I can follow
> simple rules. And I could then bring in my CalendarMaker component, or some
> other cool functionality which would otherwise be absurd for me to consider
> contributing. (not a real example). And no-one else would be pimped in the
> process, which is the most important part.
That sounds good. But then again I don't see a huge need for evolution to
occur in that way. I tend to come from a more XP development methodology
where you evolve both the interface and the implementation until a point
where they can be considered mature enough.
Anyways I would not mind seeing some of this mail and your page merged into
avalons main docs ;)
--
Cheers,
Pete
*------------------------------------------------------*
| Hlade's Law: If you have a difficult task, give it |
| to a lazy person -- they will find an easier |
| way to do it. |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Separation of Interface from Implementation visuals
Posted by Paul Hammant <Pa...@yahoo.com>.
Pete,
>Yes Paul, I was trying to write my visuals to compliment your textual/academic material, but no idea if that goal was acheived.
>
>My concern is that COP is not as understandable to some of us with lesser grey matter, using myself as a guide. If it can't be reduced to pictures, some of us just can't get there. Being dim witted is not always fun. I've been studying Avalon for weeks now, and I only just "got" Roles yesterday, and only because Berin had to write me an email!
>
You are making a big mistake dude...... do not confuse me with the
smarter dudes present here ;-)
>A more specific fear, is those like myself, who think they understand it, but spend a couple weeks designing some new component to contribute that assumes a new "ROLE" or "Work Interface" which is not based on some a set of standard API's call signatures, but instead based on their own component.
>
>So then the Paul, Leo, Peter, Berin and Federico have to either
>a.) break the guy's heart, or
>b.) tell him he has to re-write it so it works with JXXX and JYYY call signatures, and decouple his own, or
>c.) do it for him, or
>d.) just bring it in anyway.
>Not good choices. So how to let people know in advance and make sure that they really "got it." ?
>
>The same is true with Separation of Concerns. Most of the actual work is in the code of the implementation, but most of the VALUE is in making the ROLE or Work Interface sensible enough for future pluggability. Again, everything hinges on that interface. And because the committers already understand this obvious fact so deeply, it never gets the emphasis in the otherwise excellent and very helpful documentation on the site. It is just kind of assumed that the reader will figure out how totally pivotal the call signature of the ROLE is to future pluggability.
>
>The flip side is that the promise of COP is so insanely huge. This really is the holy grail, if it could be made to work for the average fellow. Source forge is full of very cool things that I would never think of trying, (for example), not because they wouldn't help me, but because of the horrible prospect of tight coupling. But give me a way to bring them in loosely coupled......without fear of pimping the rest of Avalon in the process, and......
>
>The way I see it, Paul, Leo, Peter, Berin and Federico would publish in bold type a page for contributors that went like this:
>Want to contribute your Implementation or Component?
>1. Design the interface per some very standard JBLAH or other API's
>2. Submit the interface as a formal ROLE
>[stop, do not proceed beyond this point]
>3. When approved, then and only then, write your component.
>4. If you have non-standard public calls that your component requires, that is fine, but they need to be made in a separate ROLE so as not to pimp the rest of us who don't want to make them.
>5. Submit your component.
>
No, I kinda disagree. I really like the principle of evolving things up
to a publication or release point. It is two ways, aspects of interface
affect impl and V.V determined on a merit basis. It gets final whene
releases are done... i.e. a month ago we had a heated discussion about
our established ComponentManager versus what is now known as
ServiceManager. Some of uss foolishly felt mugging CompMgr to be
ServiceMgr was OK.
>This would allow lesser brained individuals such as myself, a "See Dick Run" level of guidance. A simple roadmap to follow, as even I can follow simple rules. And I could then bring in my CalendarMaker component, or some other cool functionality which would otherwise be absurd for me to consider contributing. (not a real example). And no-one else would be pimped in the process, which is the most important part.
>
Man. I would just interively publish interface and impl if I were you
until your nay-sayers are silent. There is also the possibility that
the comp just does not fit Avalon, but hey, there are loads politely
honest (and a few blunt) people here.
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Separation of Interface from Implementation visuals
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Paul Hammant wrote:
><snip>I did this (
> http://jakarta.apache.org/avalon/framework/separation-of-interface-and-implementation.html
> ) at the beginning of the week.
>
Yes Paul, I was trying to write my visuals to compliment your textual/academic material, but no idea if that goal was acheived.
My concern is that COP is not as understandable to some of us with lesser grey matter, using myself as a guide. If it can't be reduced to pictures, some of us just can't get there. Being dim witted is not always fun. I've been studying Avalon for weeks now, and I only just "got" Roles yesterday, and only because Berin had to write me an email!
A more specific fear, is those like myself, who think they understand it, but spend a couple weeks designing some new component to contribute that assumes a new "ROLE" or "Work Interface" which is not based on some a set of standard API's call signatures, but instead based on their own component.
So then the Paul, Leo, Peter, Berin and Federico have to either
a.) break the guy's heart, or
b.) tell him he has to re-write it so it works with JXXX and JYYY call signatures, and decouple his own, or
c.) do it for him, or
d.) just bring it in anyway.
Not good choices. So how to let people know in advance and make sure that they really "got it." ?
The same is true with Separation of Concerns. Most of the actual work is in the code of the implementation, but most of the VALUE is in making the ROLE or Work Interface sensible enough for future pluggability. Again, everything hinges on that interface. And because the committers already understand this obvious fact so deeply, it never gets the emphasis in the otherwise excellent and very helpful documentation on the site. It is just kind of assumed that the reader will figure out how totally pivotal the call signature of the ROLE is to future pluggability.
The flip side is that the promise of COP is so insanely huge. This really is the holy grail, if it could be made to work for the average fellow. Source forge is full of very cool things that I would never think of trying, (for example), not because they wouldn't help me, but because of the horrible prospect of tight coupling. But give me a way to bring them in loosely coupled......without fear of pimping the rest of Avalon in the process, and......
The way I see it, Paul, Leo, Peter, Berin and Federico would publish in bold type a page for contributors that went like this:
Want to contribute your Implementation or Component?
1. Design the interface per some very standard JBLAH or other API's
2. Submit the interface as a formal ROLE
[stop, do not proceed beyond this point]
3. When approved, then and only then, write your component.
4. If you have non-standard public calls that your component requires, that is fine, but they need to be made in a separate ROLE so as not to pimp the rest of us who don't want to make them.
5. Submit your component.
This would allow lesser brained individuals such as myself, a "See Dick Run" level of guidance. A simple roadmap to follow, as even I can follow simple rules. And I could then bring in my CalendarMaker component, or some other cool functionality which would otherwise be absurd for me to consider contributing. (not a real example). And no-one else would be pimped in the process, which is the most important part.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Separation of Interface from Implementation visuals
Posted by Paul Hammant <Pa...@yahoo.com>.
Pete,
Good work. I'll read your work some more later, but should chip in and
say that I dud this (
http://jakarta.apache.org/avalon/framework/separation-of-interface-and-implementation.html
) at the beginning of the week.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Separation of Interface from Implementation visuals
Posted by Leo Simons <le...@apache.org>.
> As relates the jar issue, since it didn't seem to be part of the
> Interface/Impl question except in passing, I thought that would
> best be saved for another graphic. Let me know if you feel
> strongly that it must be included here.
You are, of course, quite right. The relationship lies in the fact
that if you are not able to package and seal jars in the described
way, you probably have made a few mistakes when doing separation
of interface & implementation.
> Regarding your request for me to xdoc this, I have never done
> that before. Is it simply a matter of closing all my HTML tags?
> Or is there a site somewhere I should go to introduce myself to a
> specific methodology?
The Jakarta site is generated from XML documents. These are in the
src/xdocs directory for any source distribution or in CVS. The
format in use for these docs is specified by a DTD in src/xdocs/dtd.
More information about the process used when building the site is
at http://jakarta.apache.org/site/jakarta-site2.html. Avalon uses
a slightly modified system from what is described here, though.
You definately won't need to read it all to create a valid xdoc.
If you know XML, and CVS, I suggest you checkout the jakarta-avalon
module (see http://jakarta.apache.org/site/cvsindex.html) and have
a look around in the src/xdocs directory within. I suspect you
won't have much trouble creating a usable xml document by following
the sources.
If not, well, you might need to learn a little about both before
you continue. (http://www.cvshome.org/ and www.xml.com).
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Separation of Interface from Implementation visuals
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Leo:
Reply to your comments and suggestions from below.
As relates the jar issue, since it didn't seem to be part of the Interface/Impl question except in passing, I thought that would best be saved for another graphic. Let me know if you feel strongly that it must be included here.
Regarding your request for me to xdoc this, I have never done that before. Is it simply a matter of closing all my HTML tags? Or is there a site somewhere I should go to introduce myself to a specific methodology?
Thanks,
Pete Carapetyan
Leo Simons wrote:
>
> very nice!
>
> I'm not good at visual explanations, but you did make me look
> at an old concept (for me, it's in the "well, doh!" category
> by now) in a new way.
>
> Something that you didn't address completely is the
> packaging (there's jars in the first graph, not in the later
> ones).
>
> We would of course have
>
> 1 jbar-interface.jar jbar-interface-myExtension.jar
> | |
> | implements | implements
> | |
> 2 jbar-myImplementation.jar jbar-myImplementation-myExtension.jar
> | |
> | contains | contains
> | |
> 3 jbar-myimplementation-complete.jar
>
> where either the second or third layer is optional. And with regards to
> Jimmy,
> he would then:
>
> 1 jbar-interface.jar jbar-interface-myExtension.jar
> jbar-interface-jimmyExtension.jar
> | | |
> | implements | implements | implements
> | | |
> 2 jbar-myImplementation.jar jbar-myImplementation-myExtension.jar
> jbar-jimmyImplementation-jimmyExtension.jar
> | | |
> | contains | contains |
> | | |
> 3 jbar-myimplementation-complete.jar |
> | |
> | dependency /-----------------------------------------/
> | |
> 4 jbar-jimmyImplementation-complete.jar
>
> note on the relationships: implements implies dependency.
> So an implementation-xxx.jar depends on an interface-xxx.jar.
>
> It would be really cool if you could make some of these
> changes and create an xml (xdoc) document out of all this...
>
> cheers,
>
> - Leo Simons, who finally had A Good Night Of Sleep(tm) again last night
>
> > -----Oorspronkelijk bericht-----
> > Van: Pete Carapetyan [mailto:pete@datafundamentals.com]
> > Verzonden: Friday, April 05, 2002 6:58 PM
> > Aan: Avalon Developers List
> > Onderwerp: Separation of Interface from Implementation visuals
> >
> >
> > Separation of Interface/Implementation
> >
> > At the risk of exposing myself as a person with a small mind, I
> > am submitting a draft visual for approval of the Separation of
> > Implementation from Interface. Couldn't seem to work it out,
> > without the visuals.
> >
> > The problem for me is simple. Inversion of Control and Separation
> > of Concerns really help, but my interest is in true pluggability.
> > True pluggability falls apart like a big dog, right when the
> > first guy that writes a component defines the interface just by
> > being nice enough to contribute an implementation.
> >
> > He didn't intend to mess up the interface, but if the interface
> > is not defined by some standard API rather than his custom
> > implementation, no amount of good intentions makes it possible
> > for the next guy to follow behind. So that is the problem.
> >
> > If the problem is simple, the solution did not seem so simple.
> > This is because of the many to many relationship between APIs and
> > interfaces, and the one to many relationship between an
> > implementation and interfaces. A strictly hierarchical approach
> > doesn't work in all cases, so I had to map it out visually to
> > figure out if it was even possible to come up with a methodology
> > that would work for everything.
> >
> > What follows is a first draft. It is intended that smarter
> > persons than myself will find many logic errors, and I will
> > correct the visuals accordingly. When ready, or at any time, the
> > Avalon committers may submit at their discretion, to add to what
> > is already written on Interface/Impl.
> >
> > http://couldbe.net/InterfaceImpl/
> >
> > Thanks for your help in sorting this out.
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] Callback Iteration(1)
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,
Excellent work dude & welcome to the Avalon list.
I'll poke thru these in the morning :-)
- Paul
>Hi,
>Attached herewith is the first Iteration of the
>*Callback* feature for *Altrmi* :->
>1. callback.patch (cvs diff for existing code)
>2. callback-new-files.zip (archive of new files to be
>add'd)
>
>Among the archives is a sample illustrating
>this new feature too.
>(callback.xml script has the essential targets
>{server^client} to run this example too)
>
>Regards,
>V i n a y
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Tax Center - online filing with TurboTax
>http://taxes.yahoo.com/
>
>
>------------------------------------------------------------------------
>
>cvs -q diff (in directory C:\avalon\cvs\jakarta-avalon-excalibur\altrmi\src\java\org\apache\excalibur\altrmi)
>? client/impl/socket/CallbackEnabledCustomSocketStreamInvocationHandler.java
>? client/impl/socket/CallbackEnabledCustomSocketStreamHostContext.java
>? client/impl/stream/CallbackEnabledClientCustomStreamReadWriter.java
>? common/AltrmiCallbackException.java
>? common/ExposedObjectProxy.java
>? server/impl/CallbackEnabledCustomSocketStreamReadWriter.java
>? server/impl/socket/CallbackEnabledCustomSocketStreamServer.java
>Index: client/impl/BaseServedObject.java
>===================================================================
>RCS file: /home/cvspublic/jakarta-avalon-excalibur/altrmi/src/java/org/apache/excalibur/altrmi/client/impl/BaseServedObject.java,v
>retrieving revision 1.1
>diff -r1.1 BaseServedObject.java
>29a30,33
>
>>//callback
>>import org.apache.excalibur.altrmi.common.ExposedObjectProxy;
>>import org.apache.excalibur.altrmi.client.impl.socket.CallbackEnabledCustomSocketStreamInvocationHandler;
>>
>47c51,54
><
>---
>
>> //<callback related>
>> private boolean mbIsCallbackAware=false;
>> private CallbackEnabledCustomSocketStreamInvocationHandler mCallbackEnabledCustomSocketStreamInvocationHandler=null;
>> //</callback related>
>>
>70a78,86
>
>> //<callback related>
>> if(mInvocationHandler instanceof CallbackEnabledCustomSocketStreamInvocationHandler)
>> {
>>
>> mCallbackEnabledCustomSocketStreamInvocationHandler =
>> (CallbackEnabledCustomSocketStreamInvocationHandler)mInvocationHandler;
>> mbIsCallbackAware=true;
>> }
>> //</callback related>
>>
>326a343,351
>
>> else if(mbIsCallbackAware)
>> {
>> String publishedName = mCallbackEnabledCustomSocketStreamInvocationHandler.getPublishedName(args[i]);
>> if(publishedName!=null)
>> {
>> ExposedObjectProxy exposedObjectProxy = new ExposedObjectProxy(publishedName);
>> args[i]=exposedObjectProxy;
>> }
>> }
>>
>Index: generator/ProxyGeneratorImpl.java
>===================================================================
>RCS file: /home/cvspublic/jakarta-avalon-excalibur/altrmi/src/java/org/apache/excalibur/altrmi/generator/ProxyGeneratorImpl.java,v
>retrieving revision 1.1
>diff -r1.1 ProxyGeneratorImpl.java
>14d13
>< import org.apache.excalibur.altrmi.test.TestInterface;
>Index: server/impl/classretrievers/PlainClassRetriever.java
>===================================================================
>RCS file: /home/cvspublic/jakarta-avalon-excalibur/altrmi/src/java/org/apache/excalibur/altrmi/server/impl/classretrievers/PlainClassRetriever.java,v
>retrieving revision 1.1
>diff -r1.1 PlainClassRetriever.java
>60c60
>< is = mClassLoader.getResourceAsStream(thingName);
>---
>
>> is = mClassLoader.getResourceAsStream(thingName+".class");
>>
>>
>>------------------------------------------------------------------------
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] Callback Iteration(1)
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,
>I guess it must be the changes we missed to do to the
>callback/test classes.
>The CallBackTestServer and CallBackTestClient
>must use CallbackEnabled Server and HostContext
>respectively for callback's to work properly.
>The errors are thus due to the fact that
>the arg's are been serialized and passed-by-value to
>the server when we use SocketCustomStreamHostContext.
>
>Moreover there is another modification that needs to
>be
>done to the build script (callback.xml),
>one that generates the proxies for the callback stub
>for the clients.
>(stubs for CallBackListener inf.)
>
>Attached patches must do the trick :-
>
The callback works, but I am holding back from a commit as 'socketa' and
'piped' are not working now. It seems to hand during the first of the
'ten seconds' tests.
I'll try to find out if it is something I have done later on....
>Do let me know how this patch works at your end ?
>
No, when attached in email like this, one of a couple of servers to SMTP
clients applies a word wrap to the patch that makes them unappliable.
For me, I am always happiest recieving whole files
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] Callback Iteration(1)
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,
Ah yes.... Doh!
It is too late now to reapply again so I will get to this in the
morning... :-)
- Paul
>Paul,
>I guess it must be the changes we missed to do to the
>callback/test classes.
>The CallBackTestServer and CallBackTestClient
>must use CallbackEnabled Server and HostContext
>respectively for callback's to work properly.
>The errors are thus due to the fact that
>the arg's are been serialized and passed-by-value to
>the server when we use SocketCustomStreamHostContext.
>
>Moreover there is another modification that needs to
>be
>done to the build script (callback.xml),
>one that generates the proxies for the callback stub
>for the clients.
>(stubs for CallBackListener inf.)
>
>Attached patches must do the trick :-
>
>Do let me know how this patch works at your end ?
>
>Regards,
>V i n a y
>===============================
>cvs -q diff callback.xml (in directory
>C:\avalon\cvs\jakarta-avalon-excalibur\altrmi)
>Index: callback.xml
>===================================================================
>RCS file:
>/home/cvspublic/jakarta-avalon-excalibur/altrmi/callback.xml,v
>retrieving revision 1.2
>diff -r1.2 callback.xml
>9c9
><
>---
>
>> <property file="default.properties"/> <!-- User
>>
>local -->
>60c60,67
><
>---
>
>> <altrmiproxies genname="CallBackTestListenerImpl"
>>
>srcgendir="${build.home}/genjava"
>
>> classgendir="${build.home}/genclasses"
>>
>verbose="true"
>
>>
>>
>interfaces="org.apache.excalibur.altrmi.test.callback.CallBackTestListener">
>
>> <classpath>
>> <pathelement
>>
>location="${build.home}/classes"/>
>
>> </classpath>
>> </altrmiproxies>
>>
>63c70
>< <target name="server" description="Callback test
>server">
>---
>
>> <target name="server" description="Callback test
>>
>server" depends="generate">
>72c79
>< <target name="client" description="Callback test
>client" depends="generate">
>---
>
>> <target name="client" description="Callback test
>>
>client" >
>
>*****CVS exited normally with code 1*****
>
>cvs -q diff CallBackTestClient.java (in directory
>C:\avalon\cvs\jakarta-avalon-excalibur\altrmi\src\test\org\apache\excalibur\altrmi\test\callback)
>Index: CallBackTestClient.java
>===================================================================
>RCS file:
>/home/cvspublic/jakarta-avalon-excalibur/altrmi/src/test/org/apache/excalibur/altrmi/test/callback/CallBackTestClient.java,v
>retrieving revision 1.2
>diff -r1.2 CallBackTestClient.java
>46c46
>< arhc = new
>SocketCustomStreamHostContext("127.0.0.1", 1235);
>---
>
>> arhc = new
>>
>CallbackEnabledCustomSocketStreamHostContext("127.0.0.1",
>1235);
>
>*****CVS exited normally with code 1*****
>
>cvs -q diff CallBackTestServer.java (in directory
>C:\avalon\cvs\jakarta-avalon-excalibur\altrmi\src\test\org\apache\excalibur\altrmi\test\callback)
>Index: CallBackTestServer.java
>===================================================================
>RCS file:
>/home/cvspublic/jakarta-avalon-excalibur/altrmi/src/test/org/apache/excalibur/altrmi/test/callback/CallBackTestServer.java,v
>retrieving revision 1.2
>diff -r1.2 CallBackTestServer.java
>18a19
>
>42c43
>< AbstractServer as = new
>CompleteSocketCustomStreamServer(1235);
>---
>
>> AbstractServer as = new
>>
>CallbackEnabledCustomSocketStreamServer(1235);
>
>
>===============================
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Tax Center - online filing with TurboTax
>http://taxes.yahoo.com/
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] Callback Iteration(1)
Posted by Vinay Chandran <vi...@yahoo.com>.
Paul,
I guess it must be the changes we missed to do to the
callback/test classes.
The CallBackTestServer and CallBackTestClient
must use CallbackEnabled Server and HostContext
respectively for callback's to work properly.
The errors are thus due to the fact that
the arg's are been serialized and passed-by-value to
the server when we use SocketCustomStreamHostContext.
Moreover there is another modification that needs to
be
done to the build script (callback.xml),
one that generates the proxies for the callback stub
for the clients.
(stubs for CallBackListener inf.)
Attached patches must do the trick :-
Do let me know how this patch works at your end ?
Regards,
V i n a y
===============================
cvs -q diff callback.xml (in directory
C:\avalon\cvs\jakarta-avalon-excalibur\altrmi)
Index: callback.xml
===================================================================
RCS file:
/home/cvspublic/jakarta-avalon-excalibur/altrmi/callback.xml,v
retrieving revision 1.2
diff -r1.2 callback.xml
9c9
<
---
> <property file="default.properties"/> <!-- User
local -->
60c60,67
<
---
> <altrmiproxies genname="CallBackTestListenerImpl"
srcgendir="${build.home}/genjava"
> classgendir="${build.home}/genclasses"
verbose="true"
>
interfaces="org.apache.excalibur.altrmi.test.callback.CallBackTestListener">
> <classpath>
> <pathelement
location="${build.home}/classes"/>
> </classpath>
> </altrmiproxies>
>
63c70
< <target name="server" description="Callback test
server">
---
> <target name="server" description="Callback test
server" depends="generate">
72c79
< <target name="client" description="Callback test
client" depends="generate">
---
> <target name="client" description="Callback test
client" >
*****CVS exited normally with code 1*****
cvs -q diff CallBackTestClient.java (in directory
C:\avalon\cvs\jakarta-avalon-excalibur\altrmi\src\test\org\apache\excalibur\altrmi\test\callback)
Index: CallBackTestClient.java
===================================================================
RCS file:
/home/cvspublic/jakarta-avalon-excalibur/altrmi/src/test/org/apache/excalibur/altrmi/test/callback/CallBackTestClient.java,v
retrieving revision 1.2
diff -r1.2 CallBackTestClient.java
46c46
< arhc = new
SocketCustomStreamHostContext("127.0.0.1", 1235);
---
> arhc = new
CallbackEnabledCustomSocketStreamHostContext("127.0.0.1",
1235);
*****CVS exited normally with code 1*****
cvs -q diff CallBackTestServer.java (in directory
C:\avalon\cvs\jakarta-avalon-excalibur\altrmi\src\test\org\apache\excalibur\altrmi\test\callback)
Index: CallBackTestServer.java
===================================================================
RCS file:
/home/cvspublic/jakarta-avalon-excalibur/altrmi/src/test/org/apache/excalibur/altrmi/test/callback/CallBackTestServer.java,v
retrieving revision 1.2
diff -r1.2 CallBackTestServer.java
18a19
>
42c43
< AbstractServer as = new
CompleteSocketCustomStreamServer(1235);
---
> AbstractServer as = new
CallbackEnabledCustomSocketStreamServer(1235);
===============================
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] Callback Iteration(1)
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,
I am not quite sure what you are saying dude.
Yes, I have committed some changes :
1) To the Callback test, which could not have run as was.
2) To the xdocs for AltRMI to allow the xdocs to refer to the api docs.
But I have not committed the changes I reapplied from your three emails
to src/java as it did not pass the test
ant -buildfile callback.xml server
ant -buildfile callback.xml client
If you are saying there are problems, then it is possible that I have
not applied your changes correctly. Perhaps sending a fresh set of Java
sources from you src/java tree (no patch files) will help me.....
Regards,
- Paul
>Paul,
>
>I dont get this ;-?
>Am I looking at the right place,Paul?
>(http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-excalibur/altrmi/
>)
>
>The cvs @excalibur doesNOT reflect my recent callback
>patches and thus the barfs.
>
>Regards,
>V i n a y
>
>
>
>--- Paul Hammant <Pa...@yahoo.com> wrote:
>
>>Vinay,
>>
>>I have reapplied all the patches and the test barfs
>>as follows :
>>
>> [java] Registering CallBackTestListenerImpls
>>with the CallBackTest
>> [java] java.io.NotSerializableException:
>>
>org.apache.excalibur.altrmi.test.callback.CallBackTestListenerImpl
>
>> [java] at
>>
>java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
>
>> [java] at
>>
>java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1224)
>
>> [java] at
>>
>java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1050)
>
>> [java] at
>>
>java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
>
>> [java] at
>>
>org.apache.excalibur.altrmi.common.MethodRequest.writeExternal(MethodRequest.java:147)
>
>> [java] at
>>
>java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1265)
>
>> [java] at
>>
>java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1243)
>
>> [java] at
>>
>java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
>
>> [java] at
>>
>java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
>
>> [java] at
>>
>org.apache.excalibur.altrmi.common.SerializationHelper.getBytesFromInstance(SerializationHelper.java:49)
>
>> [java] at
>>
>org.apache.excalibur.altrmi.client.impl.stream.ClientCustomStreamReadWriter.writeRequest(ClientCustomStreamReadWriter.java:74)
>
>> [java] at
>>
>org.apache.excalibur.altrmi.client.impl.stream.ClientCustomStreamReadWriter.postRequest(ClientCustomStreamReadWriter.java:64)
>
>> [java] at
>>
>org.apache.excalibur.altrmi.client.impl.stream.StreamInvocationHandler.handleInvocation(StreamInvocationHandler.java:140)
>
>> [java] at
>>
>org.apache.excalibur.altrmi.client.impl.BaseServedObject.processObjectRequest(BaseServedObject.java:227)
>
>> [java] at
>>
>AltrmiGeneratedCallbackTest_Main.addCallBackListener(AltrmiGeneratedCallbackTest_Main.java:29)
>
>> [java] at
>>
>org.apache.excalibur.altrmi.test.callback.CallBackTestClient.main(CallBackTestClient.java:75)
>
>>Have a check of it your end dude...
>>
>>Regards,
>>
>>- Paul
>>
>>>Paul,
>>>I did kind of do that (exposeObject(..) on purpose
>>>
>>,
>>
>>>something I tried to model along the lines of our
>>>
>>RMI
>>
>>>dame.
>>>[UnicastRemoteObject.exportObject(..) ..]
>>>But I guess the way you have illustrated through
>>>
>>test
>>
>>>cases checked in test/callback/ files
>>>is also feasible ; & definitely more kewler.
>>>gr8 suggestion dude and it does make sense.
>>>And attached here is the patch to get rid of
>>>the exposeObject(..) kind of call .
>>>[There was another method within
>>>CallbackInvocationHandler which had to be
>>>
>>public'zed
>>
>>>]
>>>I guess now the test cases that you kindly checked
>>>in for me , should work too .
>>>(after the proper imports of callback
>>>factories/servers)
>>>
>>>The BaseServedObject marshallerer now checks the
>>>typs of arguments and accordingly publishes
>>>the obj with the internal altrmiServer.
>>>BTW,
>>>the callback.xml must create the stub for the
>>>CallBackTestListener too or we should generate it
>>>through code .( I shall start the brain-surgery
>>>on stubs using BCEL after we are through with
>>>
>>settling
>>
>>>the dust over callbacks)
>>>
>>>
>>>Regards,
>>>V i n a y
>>>
>>>
>>>
>>>__________________________________________________
>>>Do You Yahoo!?
>>>Yahoo! Tax Center - online filing with TurboTax
>>>http://taxes.yahoo.com/
>>>
>>>
>>------------------------------------------------------------------------
>>
>>>cvs diff BaseServedObject.java (in directory
>>>
>C:\vinay\jc\jakarta-avalon-excalibur\altrmi\src\java\org\apache\excalibur\altrmi\client\impl)
>
>>>Index: BaseServedObject.java
>>>
>>===================================================================
>>
>>>RCS file:
>>>
>/home/cvspublic/jakarta-avalon-excalibur/altrmi/src/java/org/apache/excalibur/altrmi/client/impl/BaseServedObject.java,v
>
>>>retrieving revision 1.1
>>>diff -r1.1 BaseServedObject.java
>>>29a30,34
>>>
>>>>//callback
>>>>import
>>>>
>org.apache.excalibur.altrmi.common.ExposedObjectProxy;
>
>>>>import
>>>>
>org.apache.excalibur.altrmi.client.impl.socket.CallbackEnabledCustomSocketStreamInvocationHandler;
>
>>>>import java.util.StringTokenizer;
>>>>import
>>>>
>org.apache.excalibur.altrmi.common.AltrmiCallbackException;
>
>>>47c52,55
>>><
>>>---
>>>
>>>> //<callback related>
>>>> private boolean mbIsCallbackAware=false;
>>>> private
>>>>
>>CallbackEnabledCustomSocketStreamInvocationHandler
>>
>mCallbackEnabledCustomSocketStreamInvocationHandler=null;
>
>>>> //</callback related>
>>>>
>>>70a79,87
>>>
>>>> //<callback related>
>>>> if(mInvocationHandler instanceof
>>>>
>>CallbackEnabledCustomSocketStreamInvocationHandler)
>>
>>>> {
>>>>
>>>>
>>>>
>>mCallbackEnabledCustomSocketStreamInvocationHandler
>>=
>>
>>>>
>>>>
>(CallbackEnabledCustomSocketStreamInvocationHandler)mInvocationHandler;
>
>>>> mbIsCallbackAware=true;
>>>> }
>>>> //</callback related>
>>>>
>>>206c223
>>>< marshallCorrection(args);
>>>---
>>>
>>>> marshallCorrection(methodSignature,args);
>>>>
>>>312c329,332
>>>< private void marshallCorrection(Object[]
>>>
>>args) {
>>
>>>---
>>>
>>>> private void marshallCorrection(String
>>>>
>>methodSignature , Object[] args) {
>>
>>>> String _methodArgumentClasses =
>>>>
>methodSignature.substring(methodSignature.indexOf("(")+1,methodSignature.lastIndexOf(")"));
>
>>>> StringTokenizer _methodArgumentClassTokens = new
>>>>
>>StringTokenizer(_methodArgumentClasses,",");
>>
>>>314a335,346
>>>
>>>>
>>>> String
>>>>
>>_sArgClass=_methodArgumentClassTokens.nextToken();
>>
>>>> Class _cArgClass=null;
>>>> try
>>>> {
>>>>
>>>> _cArgClass=Class.forName(_sArgClass);
>>>> }
>>>> catch(ClassNotFoundException cnfe)
>>>> {
>>>> System.err.println("Class "+_sArgClass +" Not
>>>>
>>Found");
>>
>>>> }
>>>>
>>>326a359,388
>>>
>>>> else if(mbIsCallbackAware)
>>>> {
>>>> String publishedName =
>>>>
>mCallbackEnabledCustomSocketStreamInvocationHandler.getPublishedName(args[i]);
>
>>>> if(publishedName!=null) //already published
>>>> {
>>>> ExposedObjectProxy exposedObjectProxy = new
>>>>
>>ExposedObjectProxy(publishedName);
>>
>>>> args[i]=exposedObjectProxy;
>>>> }
>>>> else //check whether its Publish'able
>>>> {
>>>> if(!_cArgClass.isInterface()) //Hey do we
>>>>
>>handle only interfaces?
>>
>>>> continue;
>>>>
>>>>
>>if(_cArgClass.isAssignableFrom(args[i].getClass()))
>>
>>>> {
>>>> try
>>>> {
>>>>
>=== message truncated ===
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Tax Center - online filing with TurboTax
>http://taxes.yahoo.com/
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] Callback Iteration(1)
Posted by Vinay Chandran <vi...@yahoo.com>.
Paul,
I dont get this ;-?
Am I looking at the right place,Paul?
(http://cvs.apache.org/viewcvs.cgi/jakarta-avalon-excalibur/altrmi/
)
The cvs @excalibur doesNOT reflect my recent callback
patches and thus the barfs.
Regards,
V i n a y
--- Paul Hammant <Pa...@yahoo.com> wrote:
> Vinay,
>
> I have reapplied all the patches and the test barfs
> as follows :
>
> [java] Registering CallBackTestListenerImpls
> with the CallBackTest
> [java] java.io.NotSerializableException:
>
org.apache.excalibur.altrmi.test.callback.CallBackTestListenerImpl
> [java] at
>
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
> [java] at
>
java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1224)
> [java] at
>
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1050)
> [java] at
>
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
> [java] at
>
org.apache.excalibur.altrmi.common.MethodRequest.writeExternal(MethodRequest.java:147)
> [java] at
>
java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1265)
> [java] at
>
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1243)
> [java] at
>
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
> [java] at
>
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
> [java] at
>
org.apache.excalibur.altrmi.common.SerializationHelper.getBytesFromInstance(SerializationHelper.java:49)
> [java] at
>
org.apache.excalibur.altrmi.client.impl.stream.ClientCustomStreamReadWriter.writeRequest(ClientCustomStreamReadWriter.java:74)
> [java] at
>
org.apache.excalibur.altrmi.client.impl.stream.ClientCustomStreamReadWriter.postRequest(ClientCustomStreamReadWriter.java:64)
> [java] at
>
org.apache.excalibur.altrmi.client.impl.stream.StreamInvocationHandler.handleInvocation(StreamInvocationHandler.java:140)
> [java] at
>
org.apache.excalibur.altrmi.client.impl.BaseServedObject.processObjectRequest(BaseServedObject.java:227)
> [java] at
>
AltrmiGeneratedCallbackTest_Main.addCallBackListener(AltrmiGeneratedCallbackTest_Main.java:29)
> [java] at
>
org.apache.excalibur.altrmi.test.callback.CallBackTestClient.main(CallBackTestClient.java:75)
>
> Have a check of it your end dude...
>
> Regards,
>
> - Paul
>
> >Paul,
> >I did kind of do that (exposeObject(..) on purpose
> ,
> >something I tried to model along the lines of our
> RMI
> >dame.
> >[UnicastRemoteObject.exportObject(..) ..]
> >But I guess the way you have illustrated through
> test
> >cases checked in test/callback/ files
> >is also feasible ; & definitely more kewler.
> >gr8 suggestion dude and it does make sense.
> >And attached here is the patch to get rid of
> >the exposeObject(..) kind of call .
> >[There was another method within
> >CallbackInvocationHandler which had to be
> public'zed
> >]
> >I guess now the test cases that you kindly checked
> >in for me , should work too .
> >(after the proper imports of callback
> >factories/servers)
> >
> >The BaseServedObject marshallerer now checks the
> >typs of arguments and accordingly publishes
> >the obj with the internal altrmiServer.
> >BTW,
> >the callback.xml must create the stub for the
> >CallBackTestListener too or we should generate it
> >through code .( I shall start the brain-surgery
> >on stubs using BCEL after we are through with
> settling
> >
> >the dust over callbacks)
> >
> >
> >Regards,
> >V i n a y
> >
> >
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Tax Center - online filing with TurboTax
> >http://taxes.yahoo.com/
> >
> >
>
>------------------------------------------------------------------------
> >
> >cvs diff BaseServedObject.java (in directory
>
C:\vinay\jc\jakarta-avalon-excalibur\altrmi\src\java\org\apache\excalibur\altrmi\client\impl)
> >Index: BaseServedObject.java
>
>===================================================================
> >RCS file:
>
/home/cvspublic/jakarta-avalon-excalibur/altrmi/src/java/org/apache/excalibur/altrmi/client/impl/BaseServedObject.java,v
> >retrieving revision 1.1
> >diff -r1.1 BaseServedObject.java
> >29a30,34
> >
> >>//callback
> >>import
>
org.apache.excalibur.altrmi.common.ExposedObjectProxy;
> >>import
>
org.apache.excalibur.altrmi.client.impl.socket.CallbackEnabledCustomSocketStreamInvocationHandler;
> >>import java.util.StringTokenizer;
> >>import
>
org.apache.excalibur.altrmi.common.AltrmiCallbackException;
> >>
> >47c52,55
> ><
> >---
> >
> >> //<callback related>
> >> private boolean mbIsCallbackAware=false;
> >> private
> CallbackEnabledCustomSocketStreamInvocationHandler
>
mCallbackEnabledCustomSocketStreamInvocationHandler=null;
> >> //</callback related>
> >>
> >70a79,87
> >
> >> //<callback related>
> >> if(mInvocationHandler instanceof
> CallbackEnabledCustomSocketStreamInvocationHandler)
> >> {
> >>
> >>
> mCallbackEnabledCustomSocketStreamInvocationHandler
> =
> >>
>
(CallbackEnabledCustomSocketStreamInvocationHandler)mInvocationHandler;
> >> mbIsCallbackAware=true;
> >> }
> >> //</callback related>
> >>
> >206c223
> >< marshallCorrection(args);
> >---
> >
> >> marshallCorrection(methodSignature,args);
> >>
> >312c329,332
> >< private void marshallCorrection(Object[]
> args) {
> >---
> >
> >> private void marshallCorrection(String
> methodSignature , Object[] args) {
> >>
> >> String _methodArgumentClasses =
>
methodSignature.substring(methodSignature.indexOf("(")+1,methodSignature.lastIndexOf(")"));
> >> StringTokenizer _methodArgumentClassTokens = new
> StringTokenizer(_methodArgumentClasses,",");
> >>
> >314a335,346
> >
> >>
> >> String
> _sArgClass=_methodArgumentClassTokens.nextToken();
> >> Class _cArgClass=null;
> >> try
> >> {
> >>
> >> _cArgClass=Class.forName(_sArgClass);
> >> }
> >> catch(ClassNotFoundException cnfe)
> >> {
> >> System.err.println("Class "+_sArgClass +" Not
> Found");
> >> }
> >>
> >326a359,388
> >
> >> else if(mbIsCallbackAware)
> >> {
> >> String publishedName =
>
mCallbackEnabledCustomSocketStreamInvocationHandler.getPublishedName(args[i]);
> >> if(publishedName!=null) //already published
> >> {
> >> ExposedObjectProxy exposedObjectProxy = new
> ExposedObjectProxy(publishedName);
> >> args[i]=exposedObjectProxy;
> >> }
> >> else //check whether its Publish'able
> >> {
> >> if(!_cArgClass.isInterface()) //Hey do we
> handle only interfaces?
> >> continue;
> >>
> if(_cArgClass.isAssignableFrom(args[i].getClass()))
> >> {
> >> try
> >> {
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] Callback Iteration(1)
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,
I have reapplied all the patches and the test barfs as follows :
[java] Registering CallBackTestListenerImpls with the CallBackTest
[java] java.io.NotSerializableException:
org.apache.excalibur.altrmi.test.callback.CallBackTestListenerImpl
[java] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054)
[java] at
java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1224)
[java] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1050)
[java] at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
[java] at
org.apache.excalibur.altrmi.common.MethodRequest.writeExternal(MethodRequest.java:147)
[java] at
java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1265)
[java] at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1243)
[java] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
[java] at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278)
[java] at
org.apache.excalibur.altrmi.common.SerializationHelper.getBytesFromInstance(SerializationHelper.java:49)
[java] at
org.apache.excalibur.altrmi.client.impl.stream.ClientCustomStreamReadWriter.writeRequest(ClientCustomStreamReadWriter.java:74)
[java] at
org.apache.excalibur.altrmi.client.impl.stream.ClientCustomStreamReadWriter.postRequest(ClientCustomStreamReadWriter.java:64)
[java] at
org.apache.excalibur.altrmi.client.impl.stream.StreamInvocationHandler.handleInvocation(StreamInvocationHandler.java:140)
[java] at
org.apache.excalibur.altrmi.client.impl.BaseServedObject.processObjectRequest(BaseServedObject.java:227)
[java] at
AltrmiGeneratedCallbackTest_Main.addCallBackListener(AltrmiGeneratedCallbackTest_Main.java:29)
[java] at
org.apache.excalibur.altrmi.test.callback.CallBackTestClient.main(CallBackTestClient.java:75)
Have a check of it your end dude...
Regards,
- Paul
>Paul,
>I did kind of do that (exposeObject(..) on purpose ,
>something I tried to model along the lines of our RMI
>dame.
>[UnicastRemoteObject.exportObject(..) ..]
>But I guess the way you have illustrated through test
>cases checked in test/callback/ files
>is also feasible ; & definitely more kewler.
>gr8 suggestion dude and it does make sense.
>And attached here is the patch to get rid of
>the exposeObject(..) kind of call .
>[There was another method within
>CallbackInvocationHandler which had to be public'zed
>]
>I guess now the test cases that you kindly checked
>in for me , should work too .
>(after the proper imports of callback
>factories/servers)
>
>The BaseServedObject marshallerer now checks the
>typs of arguments and accordingly publishes
>the obj with the internal altrmiServer.
>BTW,
>the callback.xml must create the stub for the
>CallBackTestListener too or we should generate it
>through code .( I shall start the brain-surgery
>on stubs using BCEL after we are through with settling
>
>the dust over callbacks)
>
>
>Regards,
>V i n a y
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Tax Center - online filing with TurboTax
>http://taxes.yahoo.com/
>
>
>------------------------------------------------------------------------
>
>cvs diff BaseServedObject.java (in directory C:\vinay\jc\jakarta-avalon-excalibur\altrmi\src\java\org\apache\excalibur\altrmi\client\impl)
>Index: BaseServedObject.java
>===================================================================
>RCS file: /home/cvspublic/jakarta-avalon-excalibur/altrmi/src/java/org/apache/excalibur/altrmi/client/impl/BaseServedObject.java,v
>retrieving revision 1.1
>diff -r1.1 BaseServedObject.java
>29a30,34
>
>>//callback
>>import org.apache.excalibur.altrmi.common.ExposedObjectProxy;
>>import org.apache.excalibur.altrmi.client.impl.socket.CallbackEnabledCustomSocketStreamInvocationHandler;
>>import java.util.StringTokenizer;
>>import org.apache.excalibur.altrmi.common.AltrmiCallbackException;
>>
>47c52,55
><
>---
>
>> //<callback related>
>> private boolean mbIsCallbackAware=false;
>> private CallbackEnabledCustomSocketStreamInvocationHandler mCallbackEnabledCustomSocketStreamInvocationHandler=null;
>> //</callback related>
>>
>70a79,87
>
>> //<callback related>
>> if(mInvocationHandler instanceof CallbackEnabledCustomSocketStreamInvocationHandler)
>> {
>>
>> mCallbackEnabledCustomSocketStreamInvocationHandler =
>> (CallbackEnabledCustomSocketStreamInvocationHandler)mInvocationHandler;
>> mbIsCallbackAware=true;
>> }
>> //</callback related>
>>
>206c223
>< marshallCorrection(args);
>---
>
>> marshallCorrection(methodSignature,args);
>>
>312c329,332
>< private void marshallCorrection(Object[] args) {
>---
>
>> private void marshallCorrection(String methodSignature , Object[] args) {
>>
>> String _methodArgumentClasses = methodSignature.substring(methodSignature.indexOf("(")+1,methodSignature.lastIndexOf(")"));
>> StringTokenizer _methodArgumentClassTokens = new StringTokenizer(_methodArgumentClasses,",");
>>
>314a335,346
>
>>
>> String _sArgClass=_methodArgumentClassTokens.nextToken();
>> Class _cArgClass=null;
>> try
>> {
>>
>> _cArgClass=Class.forName(_sArgClass);
>> }
>> catch(ClassNotFoundException cnfe)
>> {
>> System.err.println("Class "+_sArgClass +" Not Found");
>> }
>>
>326a359,388
>
>> else if(mbIsCallbackAware)
>> {
>> String publishedName = mCallbackEnabledCustomSocketStreamInvocationHandler.getPublishedName(args[i]);
>> if(publishedName!=null) //already published
>> {
>> ExposedObjectProxy exposedObjectProxy = new ExposedObjectProxy(publishedName);
>> args[i]=exposedObjectProxy;
>> }
>> else //check whether its Publish'able
>> {
>> if(!_cArgClass.isInterface()) //Hey do we handle only interfaces?
>> continue;
>> if(_cArgClass.isAssignableFrom(args[i].getClass()))
>> {
>> try
>> {
>> mCallbackEnabledCustomSocketStreamInvocationHandler.exposeObject(args[i],_cArgClass);
>> }
>> catch(AltrmiCallbackException ace)
>> {
>> ace.printStackTrace();
>> }
>> publishedName = mCallbackEnabledCustomSocketStreamInvocationHandler.getPublishedName(args[i]);
>> ExposedObjectProxy exposedObjectProxy = new ExposedObjectProxy(publishedName);
>> args[i]=exposedObjectProxy;
>>
>> }
>>
>> }
>> }
>>
>>
>>------------------------------------------------------------------------
>>
>>/*
>> * Copyright (C) The Apache Software Foundation. All rights reserved.
>> *
>> * This software is published under the terms of the Apache Software License
>> * version 1.1, a copy of which has been included with this distribution in
>> * the LICENSE.txt file.
>> */
>>package org.apache.excalibur.altrmi.client.impl.socket;
>>
>>
>>
>>import java.io.IOException;
>>import java.io.InputStream;
>>import java.io.OutputStream;
>>
>>import org.apache.excalibur.altrmi.client.impl.stream.ClientStreamReadWriter;
>>import org.apache.excalibur.altrmi.common.*;
>>import org.apache.excalibur.altrmi.common.AltrmiConnectionException;
>>import org.apache.excalibur.altrmi.common.AltrmiCallbackException;
>>import org.apache.excalibur.altrmi.client.impl.stream.*;
>>import org.apache.excalibur.altrmi.client.impl.stream.CallbackEnabledClientCustomStreamReadWriter;
>>
>>
>>/**
>> * Class CallbackEnabledCustomSocketStreamInvocationHandler
>> *
>> * @author <a href="mailto:vinayc77@yahoo.com">Vinay Chandran</a>
>> * @version $Revision: 1.0 $
>> */
>>public final class CallbackEnabledCustomSocketStreamInvocationHandler
>> extends AbstractSocketStreamInvocationHandler {
>>
>> private CallbackEnabledClientCustomStreamReadWriter mCallbackEnabledClientCustomStreamReadWriter;
>> /*
>> * @see AbstractSocketStreamInvocationHandler#AbstractSocketStreamInvocationHandler(String, int, ClassLoader)
>> */
>> public CallbackEnabledCustomSocketStreamInvocationHandler(String host, int port, ClassLoader classLoader)
>> throws AltrmiConnectionException {
>> super(host, port, classLoader);
>> }
>>
>> /*
>> * @see AbstractSocketStreamInvocationHandler#createClientStreamReadWriter(InputStream, OutputStream)
>> */
>> protected ClientStreamReadWriter createClientStreamReadWriter(
>> InputStream in, OutputStream out) throws IOException {
>> if(mCallbackEnabledClientCustomStreamReadWriter==null)
>> {
>> mCallbackEnabledClientCustomStreamReadWriter = new CallbackEnabledClientCustomStreamReadWriter(in, out, mInterfacesClassLoader);
>> }
>> return mCallbackEnabledClientCustomStreamReadWriter;
>> }
>>
>>
>> public boolean exposeObject(Object tobeExposedObject,Class tobeExposedInterface) throws AltrmiCallbackException
>> {
>> return mCallbackEnabledClientCustomStreamReadWriter.exposeObject(tobeExposedObject,tobeExposedInterface);
>> }
>> public String getPublishedName(Object tobeExposedObject)
>> {
>> return mCallbackEnabledClientCustomStreamReadWriter.getPublishedName(tobeExposedObject);
>> }
>>}
>>
>>
>>------------------------------------------------------------------------
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [altrmi] Callback Iteration(1)
Posted by Vinay Chandran <vi...@yahoo.com>.
Paul,
I did kind of do that (exposeObject(..) on purpose ,
something I tried to model along the lines of our RMI
dame.
[UnicastRemoteObject.exportObject(..) ..]
But I guess the way you have illustrated through test
cases checked in test/callback/ files
is also feasible ; & definitely more kewler.
gr8 suggestion dude and it does make sense.
And attached here is the patch to get rid of
the exposeObject(..) kind of call .
[There was another method within
CallbackInvocationHandler which had to be public'zed
]
I guess now the test cases that you kindly checked
in for me , should work too .
(after the proper imports of callback
factories/servers)
The BaseServedObject marshallerer now checks the
typs of arguments and accordingly publishes
the obj with the internal altrmiServer.
BTW,
the callback.xml must create the stub for the
CallBackTestListener too or we should generate it
through code .( I shall start the brain-surgery
on stubs using BCEL after we are through with settling
the dust over callbacks)
Regards,
V i n a y
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
Re: [altrmi] Callback Iteration(1)
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,
OK dude I have looked at the code and think you are 85% of the way
there. Overall though an excellent effort.
The problem is that the Client the way you have coded it is very
conscious of the fact that AltRMI is in the middle. It should be
transparent. Also it looks like there can only be one callback for a
published name, I think the Callback object passed back should also
hold a reference to the sessionID and referenceID, thus the client could
register many callbacks to the same event (as would likely be the case
in normal Java).
What I have done is committed your tests (after a rename and some mods,
but still in your name). If you look at the CallBackTestClient you will
see the mods that make it transparent (the goal). Given that this test
cannot complete until the thing is working, this is a true XP style test
before impl... Also the CallBackTestClient and Server use the normal
custom stream transports (so that it compiles), these you are obviously
allowed to change :-)
Go for it dude, this will be brilliant when you have finished it (but do
remember to take your time - there is no rush)...
Regards,
- Paul
>Hi,
>Attached herewith is the first Iteration of the
>*Callback* feature for *Altrmi* :->
>1. callback.patch (cvs diff for existing code)
>2. callback-new-files.zip (archive of new files to be
>add'd)
>
>Among the archives is a sample illustrating
>this new feature too.
>(callback.xml script has the essential targets
>{server^client} to run this example too)
>
>Regards,
>V i n a y
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Tax Center - online filing with TurboTax
>http://taxes.yahoo.com/
>
>
>------------------------------------------------------------------------
>
>cvs -q diff (in directory C:\avalon\cvs\jakarta-avalon-excalibur\altrmi\src\java\org\apache\excalibur\altrmi)
>? client/impl/socket/CallbackEnabledCustomSocketStreamInvocationHandler.java
>? client/impl/socket/CallbackEnabledCustomSocketStreamHostContext.java
>? client/impl/stream/CallbackEnabledClientCustomStreamReadWriter.java
>? common/AltrmiCallbackException.java
>? common/ExposedObjectProxy.java
>? server/impl/CallbackEnabledCustomSocketStreamReadWriter.java
>? server/impl/socket/CallbackEnabledCustomSocketStreamServer.java
>Index: client/impl/BaseServedObject.java
>===================================================================
>RCS file: /home/cvspublic/jakarta-avalon-excalibur/altrmi/src/java/org/apache/excalibur/altrmi/client/impl/BaseServedObject.java,v
>retrieving revision 1.1
>diff -r1.1 BaseServedObject.java
>29a30,33
>
>>//callback
>>import org.apache.excalibur.altrmi.common.ExposedObjectProxy;
>>import org.apache.excalibur.altrmi.client.impl.socket.CallbackEnabledCustomSocketStreamInvocationHandler;
>>
>47c51,54
><
>---
>
>> //<callback related>
>> private boolean mbIsCallbackAware=false;
>> private CallbackEnabledCustomSocketStreamInvocationHandler mCallbackEnabledCustomSocketStreamInvocationHandler=null;
>> //</callback related>
>>
>70a78,86
>
>> //<callback related>
>> if(mInvocationHandler instanceof CallbackEnabledCustomSocketStreamInvocationHandler)
>> {
>>
>> mCallbackEnabledCustomSocketStreamInvocationHandler =
>> (CallbackEnabledCustomSocketStreamInvocationHandler)mInvocationHandler;
>> mbIsCallbackAware=true;
>> }
>> //</callback related>
>>
>326a343,351
>
>> else if(mbIsCallbackAware)
>> {
>> String publishedName = mCallbackEnabledCustomSocketStreamInvocationHandler.getPublishedName(args[i]);
>> if(publishedName!=null)
>> {
>> ExposedObjectProxy exposedObjectProxy = new ExposedObjectProxy(publishedName);
>> args[i]=exposedObjectProxy;
>> }
>> }
>>
>Index: generator/ProxyGeneratorImpl.java
>===================================================================
>RCS file: /home/cvspublic/jakarta-avalon-excalibur/altrmi/src/java/org/apache/excalibur/altrmi/generator/ProxyGeneratorImpl.java,v
>retrieving revision 1.1
>diff -r1.1 ProxyGeneratorImpl.java
>14d13
>< import org.apache.excalibur.altrmi.test.TestInterface;
>Index: server/impl/classretrievers/PlainClassRetriever.java
>===================================================================
>RCS file: /home/cvspublic/jakarta-avalon-excalibur/altrmi/src/java/org/apache/excalibur/altrmi/server/impl/classretrievers/PlainClassRetriever.java,v
>retrieving revision 1.1
>diff -r1.1 PlainClassRetriever.java
>60c60
>< is = mClassLoader.getResourceAsStream(thingName);
>---
>
>> is = mClassLoader.getResourceAsStream(thingName+".class");
>>
>>
>>------------------------------------------------------------------------
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[altrmi] Callback Iteration(1)
Posted by Vinay Chandran <vi...@yahoo.com>.
Hi,
Attached herewith is the first Iteration of the
*Callback* feature for *Altrmi* :->
1. callback.patch (cvs diff for existing code)
2. callback-new-files.zip (archive of new files to be
add'd)
Among the archives is a sample illustrating
this new feature too.
(callback.xml script has the essential targets
{server^client} to run this example too)
Regards,
V i n a y
__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
RE: Separation of Interface from Implementation visuals
Posted by Leo Simons <le...@apache.org>.
very nice!
I'm not good at visual explanations, but you did make me look
at an old concept (for me, it's in the "well, doh!" category
by now) in a new way.
Something that you didn't address completely is the
packaging (there's jars in the first graph, not in the later
ones).
We would of course have
1 jbar-interface.jar jbar-interface-myExtension.jar
| |
| implements | implements
| |
2 jbar-myImplementation.jar jbar-myImplementation-myExtension.jar
| |
| contains | contains
| |
3 jbar-myimplementation-complete.jar
where either the second or third layer is optional. And with regards to
Jimmy,
he would then:
1 jbar-interface.jar jbar-interface-myExtension.jar
jbar-interface-jimmyExtension.jar
| | |
| implements | implements | implements
| | |
2 jbar-myImplementation.jar jbar-myImplementation-myExtension.jar
jbar-jimmyImplementation-jimmyExtension.jar
| | |
| contains | contains |
| | |
3 jbar-myimplementation-complete.jar |
| |
| dependency /-----------------------------------------/
| |
4 jbar-jimmyImplementation-complete.jar
note on the relationships: implements implies dependency.
So an implementation-xxx.jar depends on an interface-xxx.jar.
It would be really cool if you could make some of these
changes and create an xml (xdoc) document out of all this...
cheers,
- Leo Simons, who finally had A Good Night Of Sleep(tm) again last night
> -----Oorspronkelijk bericht-----
> Van: Pete Carapetyan [mailto:pete@datafundamentals.com]
> Verzonden: Friday, April 05, 2002 6:58 PM
> Aan: Avalon Developers List
> Onderwerp: Separation of Interface from Implementation visuals
>
>
> Separation of Interface/Implementation
>
> At the risk of exposing myself as a person with a small mind, I
> am submitting a draft visual for approval of the Separation of
> Implementation from Interface. Couldn't seem to work it out,
> without the visuals.
>
> The problem for me is simple. Inversion of Control and Separation
> of Concerns really help, but my interest is in true pluggability.
> True pluggability falls apart like a big dog, right when the
> first guy that writes a component defines the interface just by
> being nice enough to contribute an implementation.
>
> He didn't intend to mess up the interface, but if the interface
> is not defined by some standard API rather than his custom
> implementation, no amount of good intentions makes it possible
> for the next guy to follow behind. So that is the problem.
>
> If the problem is simple, the solution did not seem so simple.
> This is because of the many to many relationship between APIs and
> interfaces, and the one to many relationship between an
> implementation and interfaces. A strictly hierarchical approach
> doesn't work in all cases, so I had to map it out visually to
> figure out if it was even possible to come up with a methodology
> that would work for everything.
>
> What follows is a first draft. It is intended that smarter
> persons than myself will find many logic errors, and I will
> correct the visuals accordingly. When ready, or at any time, the
> Avalon committers may submit at their discretion, to add to what
> is already written on Interface/Impl.
>
> http://couldbe.net/InterfaceImpl/
>
> Thanks for your help in sorting this out.
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Separation of Interface from Implementation visuals
Posted by Pete Carapetyan <pe...@datafundamentals.com>.
Separation of Interface/Implementation
At the risk of exposing myself as a person with a small mind, I am submitting a draft visual for approval of the Separation of Implementation from Interface. Couldn't seem to work it out, without the visuals.
The problem for me is simple. Inversion of Control and Separation of Concerns really help, but my interest is in true pluggability. True pluggability falls apart like a big dog, right when the first guy that writes a component defines the interface just by being nice enough to contribute an implementation.
He didn't intend to mess up the interface, but if the interface is not defined by some standard API rather than his custom implementation, no amount of good intentions makes it possible for the next guy to follow behind. So that is the problem.
If the problem is simple, the solution did not seem so simple. This is because of the many to many relationship between APIs and interfaces, and the one to many relationship between an implementation and interfaces. A strictly hierarchical approach doesn't work in all cases, so I had to map it out visually to figure out if it was even possible to come up with a methodology that would work for everything.
What follows is a first draft. It is intended that smarter persons than myself will find many logic errors, and I will correct the visuals accordingly. When ready, or at any time, the Avalon committers may submit at their discretion, to add to what is already written on Interface/Impl.
http://couldbe.net/InterfaceImpl/
Thanks for your help in sorting this out.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>