Re: sandbox/ThreadPool change pending
Folks, I have commit access, but not inclination without discussion, to make some changes to sandbox/threadpool... Basically, I'd like make a _backwards_ _compatible_ change to ThreadPool that allows the user to choose not not in any way use Commons-Logging. As in not depend on the jar. The default operation would be to use commons logging of course, thus making this backwards compatible. The idea is best documented here by Leo Sutic :- http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonNoLogging Note the change I have ready is not introducing a dependancy on Avalon or any other package to the codebase. Applied. - Paul -- http://www.thoughtworks.com - The art of heavy lifting. Home for many Agile practicing, Open Source activists... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox/ThreadPool change pending
I'll attach the source/patch to a following email. This one hopefully -- http://www.thoughtworks.com - The art of heavy lifting. Home for many Agile practicing, Open Source activists... tp.zip Description: Zip archive - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] promote commons attributes to the commons proper
Jon, Paul - this is all seeming a little painful to make useful progress working within Jakarta Commons. Adding 1 non-apache committer to a sandbox project seems too hard right now - we're stuck in a chicken and egg - some don't want non-apache committers working in the sandbox and some don't want us promoting a project to commons proper so we can add a new committer. Why don't we just scrap commons-attributes in the sandbox and move the project over to codehaus.org instead? Its certainly the easiest option. We're using commons-attributes in AltRMI (Incubator). To switch and use a codehaus module is that OK politically? The solution is certainly viable though. The loss to Apache would be large. Cannot we try to persuade people here that the catch-22 is worth overcoming? - Paul __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] promote commons attributes to the commons proper
+100. Count me in for coding, infrasctucture, encouragement and enthusiasm! Here's for one day seeing Nanning itself at Jakarta too (By way of Incubator of course). - Paul So that we can add some more committers to the commons-attributes projects to help unify the various attribute-replated projects out there (initially commons-attributes and Nanning but maybe eventually attrib4j too) I'd like to propose we promote commons-attributes to the commons proper. Then we can work on merging the code bases and patches and working towards an alpha release. __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Commons-Attributes (sandbox) and Jon Tirsén.
Jon has been working on attributes inside Nanning's CVS. The code we have (which is really) good is an earlier fork of that. Is there any way we can get Jon commit provs here? The version in Nanning is much more advanced than the version he donated to us earlier. If we can get some consensus, I think a vote may be a good idea. Surely he must qualify on the multi-month patch donator principle? - Paul __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re:_Commons-Attributes_(sandbox)_and_Jon_Tirsén.
Well I volunteer to help this get promoted out of sandbox. I've done work on it before (pairing with James Strachan - which he never committed - grumble grumble ;) Jon, that sound good to you ? - Paul --- robert burrell donkin [EMAIL PROTECTED] wrote: i'm against nominating committers for work on sandbox components. (apache committers should just be able to request karma and then check with the current committers that it's ok to join the fun.) if jon is an existing apache committer then he needs to post a request to the pmc cc'ing commons-dev giving some brief indications of his plans. we should then be able to sort out karma with infrastructure. IMHO if jon is not then the best solution would be for an existing apache committer to volunteer (yourself, maybe) to lead an effort to push attributes forward to a stage where it's ready for promotion to the common proper. BTW are there any copyright issues associated with the Nanning code? - robert On Sunday, June 8, 2003, at 11:33 AM, Paul Hammant wrote: Jon has been working on attributes inside Nanning's CVS. The code we have (which is really) good is an earlier fork of that. Is there any way we can get Jon commit provs here? The version in Nanning is much more advanced than the version he donated to us earlier. If we can get some consensus, I think a vote may be a good idea. Surely he must qualify on the multi-month patch donator principle? - Paul __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: _Commons-Attributes_(sandbox)_and_Jon_Tirsén.
Jon, My aim would be to see a merge of both forks of your work. Granted we have done work here, but then so have you. JSK 1.5 is not somthing I'd stop work here for. Nor would I think it is compelling to merge all OSS attrtibutes efforts. As I think is you opinion, lets just go for a update to c-a with nanning's features. Diversity, and multiple choices are great. QDox and XDoclet both exist for different niches, and high respect for each other. - Paul --- Jon Tirsén [EMAIL PROTECTED] wrote: Why implement something that's JSR175-compliant? That's gonna be part of JDK1.5 anyway. Besides it's probably not doable since it requires a language-change. Attrib4J and JSR175 has tons of extra stuff where I've always seen commons-attributes (and Nanning) as extremely simplistic, ie named attributes whose values are strings. In my experience this has been very useful and for a very small price-tag (both when it comes to learning the API, and of course implementing it). I don't see the point of putting commons-attributes in this direction (but it's not my decision to make). Why not just do it in attrib4j which has that intent? If it necessarily has to be a Jakarta-project why not start another one? On Sun, 2003-06-08 at 14:48, Ryan Hoegg wrote: I have e-mailed briefly with Mark Pollack of attrib4j.sourceforge.net. It seems some work needs to be done to support JSR175 for both commons-attributes and attrib4j. The main difference Jon and Mark have so far is the Attribute interface, where Mark would rather not have String properties for Name and Value. One interesting thing about attrib4j is that it stores its attributes in the class file instead of a separate properties file. I think that since the attribute storage mechanism is already abstracted in the current commons-attributes through the DefaultAttributeFinder and DefaultAttributeCompiler, it would make sense to agree on a common interface and create multiple implementations. I am currently a committer on ws.apache.org/xmlrpc. Can I help? -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Paul Hammant wrote: Well I volunteer to help this get promoted out of sandbox. I've done work on it before (pairing with James Strachan - which he never committed - grumble grumble ;) Jon, that sound good to you ? - Paul --- robert burrell donkin [EMAIL PROTECTED] wrote: i'm against nominating committers for work on sandbox components. (apache committers should just be able to request karma and then check with the current committers that it's ok to join the fun.) if jon is an existing apache committer then he needs to post a request to the pmc cc'ing commons-dev giving some brief indications of his plans. we should then be able to sort out karma with infrastructure. IMHO if jon is not then the best solution would be for an existing apache committer to volunteer (yourself, maybe) to lead an effort to push attributes forward to a stage where it's ready for promotion to the common proper. BTW are there any copyright issues associated with the Nanning code? - robert On Sunday, June 8, 2003, at 11:33 AM, Paul Hammant wrote: Jon has been working on attributes inside Nanning's CVS. The code we have (which is really) good is an earlier fork of that. Is there any way we can get Jon commit provs here? The version in Nanning is much more advanced than the version he donated to us earlier. If we can get some consensus, I think a vote may be a good idea. Surely he must qualify on the multi-month patch donator principle? - Paul __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Yahoo! Plus - For a better Internet experience http://uk.promotions.yahoo.com/yplus/yoffer.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Attributes] dependancy on Logging
Hi folks,
Can we consider one of two solutions for this _single_ use of commons
logging
1) Removal of the commons-logging from attributes?
2) Backwards compatible rework that will allow the application to run
without commons logging in the classpath (or classloader tree for
complex deployments).
Can I have some opinions here, or should I just dive in, make a change
and wait for the flak?
Regards,
- Paul
Folks,
In Attributes.java, there is a single use of commons logging :
public static AttributeFinder getAttributeFinder() {
} catch (Exception e) {
logger.warn(failed to initialize specified implementation +
of AttributeFinder, using default, e);
}
}
Is there a chance that we could eliminate this use given that the
system recovers with the instantiation of a default AttributeFinder ?
It would be really useful :-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Attributes] dependancy on Logging
Juozas, Can we consider one of two solutions for this _single_ use of commons logging 1) Removal of the commons-logging from attributes? 2) Backwards compatible rework that will allow the application to run without commons logging in the classpath (or classloader tree for complex deployments). I undersatnd this single use is not pragmatic, do you have problems with classloading in logging ? I have promissed to fix class loading in this component, it depends on ThreadContext classloader and it was a problem with this strategy in phoenix a year ago. logging works on phoenix at this time, does not it ? My problem is simple, I do not want to have to distribute commons-logging for because attributes depends on it. I do not want to distribute it becuase it will never get called. It is a compilation dependency only. - Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Attributes] dependancy on Logging
Juozas, Why does people get in to trouble when depending on ThreadContext classloader which is the correct way to load classes with (if one want to be container friendly :) Depending on ThreadContext classloader will work if the container follows the spec - and if there are no TCL, then use class.forname - but remmeber to do it from a method/class that is loaded with your classes own classloader /max I do not like this kind of workarounds too, but some containers heve problems with this, I do not have any problems myself, but there are a lot reports from users. Possible some users have problems to configure container and workarounds will not help. You guys chat amongst yourselves if you like. I don't want to use common logging for a _single_ (nearly-never-called) warning. That is my reason, and nothing to do with context-classloader. Regards, - Paul H - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Attributes] dependancy on Logging
Folks,
In Attributes.java, there is a single use of commons logging :
public static AttributeFinder getAttributeFinder() {
} catch (Exception e) {
logger.warn(failed to initialize specified implementation +
of AttributeFinder, using default, e);
}
}
Is there a chance that we could eliminate this use given that the system
recovers with the instantiation of a default AttributeFinder ?
It would be really useful :-)
Regards,
- Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Need interface...
Costin,
What we need is a marker interface that indicates a tool wants a logger, and
of course a method to give it the logger... I did a quick scan of the
public API, and there doesn't seem to be one.
So what I propose is to add an interface 'LogUser' or something like it (we
can quibble about the name...)
public interface LogUser
{
public void setCommonsLogger(Log log)
}
In other words, you also want a 'push' model for the logger. Curently each
component is supposed to 'pull' the logger.
Not wishing to be political, just to furnish you with info, the 'push'
model is described as 'Inversion of Control' --
http://jakarta.apache.org/avalon/framework/inversion-of-control.html
- Paul
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ALTRMI] ClassRetriever patch
Vinay, Applied, thanks dude. - Paul Paul, Patch to generate the exception correctly from classretrievers. [ getResourceStream does NOT raise any exception but returns a 'null' InputStream on failure to find a resource ] Regards, V i n a y -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ALTRMI] ProxyGenerator patch
Vinay, No I think all of them dude Thats is what interfaces are all about yes? If you want to hide methods have them in different interfaces, and don't extend from them..? - Paul Paul, We should generate proxies for calls declared in the remote interface ONLY , and should NOT generate calls in proxies for methods inherited from the base interface(or class) . Am I right ..? [See attached patch ] Regards, V i n a y Index: ProxyGeneratorImpl.java === RCS file: /home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/generator/ProxyGeneratorImpl.java,v retrieving revision 1.12 diff -r1.12 ProxyGeneratorImpl.java 252c252 Method[] methods = clazz.getMethods(); --- Method[] methods = clazz.getDeclaredMethods(); __ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ALTRMI] ProxyGenerator fix
Vinay,
Applied. Thanks for that dude.
- Paul
Paul,
The classloader fix sent proxy generation for a toss.
:-)
(we were using Class.equals(Class) .
both loaded by diff classloader's)
Here is the fix ...
Regards,
V i n a y
Index:
src/java/org/apache/commons/altrmi/generator/ProxyGeneratorImpl.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/generator/ProxyGeneratorImpl.java,v
retrieving revision 1.11
diff -r1.11 ProxyGeneratorImpl.java
564c564
if (clazz.equals(mAdditionalFacades[p]))
{
---
if
(clazz.getName().equals(mAdditionalFacades[p].getName()))
{
__
Do You Yahoo!?
Yahoo! Greetings - send holiday greetings for Easter, Passover
http://greetings.yahoo.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[AltRMI] memory leak
Vinay, ant -buildfile memleak.xml server ant -buildfile memleak.xml client This demo shows a current bug that means that memory is eaten up as more and more pass-by-reference objects are referenced on the client. We'll need to solve this with WeakHashMap (I think). Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Altrmi] Callback iteration
Vinay,
This looks good. We will be able to keep the way it is now for people
that do not need callback and have the alternate impls for that that
need callback enabled.
Keep up the good work!
I'm about to change references of classOrInterfacesToExpose to
interfacesToExpose as that is what we support and the whole design
idea behind AltRMI because of our creation of proxies. I will commit
the code and replicate it to EOB and Cornerstone, I hope there are not
too many implications for your work in progress.
Regards,
- Paul
Paul,
Skeleton work on Callback
It doesnt actually do the callback(:)))
but just mocks the way we can acheive it.
I have short-circuited the handling ,
and thus the tests work fine tooo (can you check
the performance drop),only difference being
the way data is read from the server.
Thoughts ???
(Dont apply these to the CVS )
So does the client side also does a publish(..)
call to export its client objects to its
invocation handler .
What is the deal??
Regards,
V i n a y
===
Index: SocketClientTest.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/test/SocketClientTest.java,v
retrieving revision 1.10
diff -r1.10 SocketClientTest.java
13d12
import
org.apache.commons.altrmi.client.AltrmiHostContext;
15,18c14
import
org.apache.commons.altrmi.common.AltrmiConnectionException;
import
org.apache.commons.altrmi.client.impl.socket.SocketObjectStreamHostContext;
import
org.apache.commons.altrmi.client.impl.socket.SocketCustomStreamHostContext;
import
org.apache.commons.altrmi.client.impl.ServerClassAltrmiFactory;
---
import
org.apache.commons.altrmi.client.AltrmiHostContext;
20,21c16,21
import java.io.IOException;
---
import
org.apache.commons.altrmi.client.impl.ServerClassAltrmiFactory;
import
org.apache.commons.altrmi.client.impl.socket.CallbackEnabledCustomSocketStreamHostContext;
import
org.apache.commons.altrmi.client.impl.socket.SocketCustomStreamHostContext;
import
org.apache.commons.altrmi.client.impl.socket.SocketObjectStreamHostContext;
import sun.security.krb5.internal.af;
import sun.security.krb5.internal.i;
57c57,60
} else {
---
} else
if(args[1].equals(CallbackEnabledCustomSocketStream)){
System.out.println(Callback Enabled Custom
Socket Stream);
arhc= new
CallbackEnabledCustomSocketStreamHostContext(127.0.0.1,1235);
}else {
==
Index: tests.xml
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/tests.xml,v
retrieving revision 1.12
diff -r1.12 tests.xml
141a142,150
target name=socketc-callback-client
description=Socket Client (CustomStream, client side
classes) depends=generate
java
classname=org.apache.commons.altrmi.test.SocketClientTest
fork=true
classpath refid=testA.classpath/
arg value=C/
arg
value=CallbackEnabledCustomSocketStream/
/java
/target
===
--- Paul Hammant [EMAIL PROTECTED] wrote:
Vinay,
I've committed your changes, In testing the
performance drop for
'pipeda' was between 2 6%. This is not bad. For
the direct types it
would be a bit more.
The benefit would outweigh the performace drop of
course, but maybe we
might revisit this in time... This email is a place
marker for that :-)
I've also formatted the source with JIndent, so
there may be whitespace
changes versus your local copy...
- Paul
hammant 02/03/22 14:51:37
Modified:
altrmi/src/java/org/apache/commons/altrmi/client/impl
BaseServedObject.java
altrmi/src/java/org/apache/commons/altrmi/generator
ProxyGeneratorImpl.java
altrmi/src/java/org/apache/commons/altrmi/server
AltrmiPublisher.java
altrmi/src/java/org/apache/commons/altrmi/server/impl
AbstractServer.java
DefaultMethodInvocationHandler.java
altrmi/src/java/org/apache/commons/altrmi/server/impl/adapters
PublicationAdapter.java
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Altrmi] PATCH Passing pf remote obj ' ref
Vinay,
Nice idea, but we would have to get the BEEP or homegrown multiplexer
working first, yes?
- Paul
Paul,
org.apache.commons.altrmi.client.impl.stream.StreamInvocationHandler
has synchronized handleInvocation(...) .
With little efforts I guess we can make this
class ThreadSafe and thus get rid of sync block ...
Maybe we can support async' calls with the altrmi
too ??? (todo item maybe)
Comments ...:-?
Regards,
Vinay
--- vinaysahil chandran [EMAIL PROTECTED] wrote:
Paul,
I worked with a fresh CVS checkout and it
(pipeda from tests.xml)
target works well without any hiccups ..
I wasn't able to reproduce it out at my machine .
Morevoer the patch's that I sent second time
doesn't
seems to be commited(Passing_Facade.patch).
Can you verify the way's I have employed there ???
Basically,
I have tried to pass Remote ref wrapped inside
FacadeREfHolder obj back to the Server.
( I think had written FacadeRefHolder for this
purpose but missed out on using it to wrap
arguments
sent from the client.I have just written the
function to wrapp the Facade with
FacadeRefHolder at the client side .)
I hope I have conveyed the stuff I did over the
past 2 patchs well across to you...
Regards,
V i n a y
--- Paul Hammant [EMAIL PROTECTED] wrote:
Vinay,
I have applied that too, and it is looking good.
One problem, test 'pipeda' fails now with a NPE at
this line in correct
args :
args[i] =
asih.mRefBeans.get(frh.getReferenceID());
Can you take a look dude..?
Regards,
- Paul
Paul,
No excuses , I had NOT done *ant clean*
before building the src after the changes ..
Here is the patch that I missed ...
But can you get the reason behind the
getMethodInvocationHandler(MethodRequest
mr,String
objectName) ..
Wont a more generic call like :
getMethodInvocationHandler(String puslishedname)
be better .
Comments ?
Sorry for this glitch,
Vinay
Index: AbstractServer.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/server/impl/AbstractServer.java,v
retrieving revision 1.21
diff -r1.21 AbstractServer.java
231a232,244
/**
* Method getMethodInvocationHandler
*
*
* @param publishedName
*
* @return
*
*/
public MethodInvocationHandler
getMethodInvocationHandler(String publishedName)
{
return
mInovcationHandlerAdapter.getMethodInvocationHandler(publishedName);
}
__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy
Awards®
http://movies.yahoo.com/
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Altrmi] PATCH Passing pf remote obj ' ref
Vinay,
I am unsure whether this change is a modification to the one you sent me
yesterday (redirect).
If it is not, I am in trouble because I have applied all the patches
locally, and it is still not compiling...
PipedObjectStreamServer should be declared abstract; it does not
define getMethodInvocationHandler(java.lang.String) ...
.. (and others)..
Regards,
- Paul
Paul,
Client can now passes references of remote bak
to server .
So the example that was crafted earlier
,Consumer-Provider, works fine now .
TestProvider tpi = (TestProvider) af.lookup(P);
TestConsumer tci = (TestConsumer) af.lookup(C);
tpi.getName(0);
tci.getProviderName(tpi); /// works now
This has been done by a hack in BaseServedObject.
So you can try out the examples within tests2.xml
, but I guess we still have to decorate this
build script with the logger.jars .
Comments.:-?
Regards,
V i n a y
__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/
Index: src/java/org/apache/commons/altrmi/client/impl/BaseServedObject.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/client/impl/BaseServedObject.java,v
retrieving revision 1.12
diff -r1.12 BaseServedObject.java
195a196
marshallCorrection(args);
271d271
283a284,299
private void marshallCorrection(Object[] args)
{
for (int i = 0; i args.length; i++)
{
//check whether its one of those remote ref that we got from
the server
//TODO : todo
if(mAltrmiFactory.getReferenceID(args[i])!=null)
{
String
objName=args[i].getClass().getName().substring(16);
args[i]=makeFacadeRefHolder(args[i],objName);
}
}
}
Index: src/java/org/apache/commons/altrmi/server/AltrmiPublisher.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/server/AltrmiPublisher.java,v
retrieving revision 1.5
diff -r1.5 AltrmiPublisher.java
81a82,93
/**
* Method getMethodInvocationHandler
*
*
* @param publishedName
*
* @return
*
*/
MethodInvocationHandler getMethodInvocationHandler(String publishedName);
Index:
src/java/org/apache/commons/altrmi/server/impl/DefaultMethodInvocationHandler.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/server/impl/DefaultMethodInvocationHandler.java,v
retrieving revision 1.4
diff -r1.4 DefaultMethodInvocationHandler.java
174d173
205,207c204,205
(DefaultMethodInvocationHandler)
mAltrmiPublisher.getMethodInvocationHandler(mr,
frh.getObjectName());
---
(DefaultMethodInvocationHandler)
mAltrmiPublisher.getMethodInvocationHandler(frh.getObjectName());
211a210,222
private void debug(Object[] args) {
System.out.println(*);
for (int i = 0; i args.length; i++) {
Object arg = args[i];
System.out.println(i = + i + class= +
args[i].getClass().getName() +
+ args[i].toString());
}
System.out.println(*);
}
Index: src/java/org/apache/commons/altrmi/server/impl/adapters/PublicationAdapter.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/server/impl/adapters/PublicationAdapter.java,v
retrieving revision 1.2
diff -r1.2 PublicationAdapter.java
104d103
164a164,167
public MethodInvocationHandler getMethodInvocationHandler(String publishedName)
{
return (MethodInvocationHandler) mPublishedObjects.get(publishedName);
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Db bean issue
Jason, Juozas is indeed glueing the exellent SimpleStore library into one or more of the examples for EOB. One small correction it is AltRMI not ARMI that is the underlying RMI-less transport: SimpleStore : http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/simplestore/ AltRMI : http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/altrmi/ Enterprise Object Broker : http://eob.sourceforge.net/ - Paul Hi, We are working on simplestore in commons, it kind of "Transparent Persitence" ARMI is kind of "Transparent RPC", I work on integration for both projects. You can get the firs release of complete framework on sourceforge EOB. I am going to work on security and transaction then persitence in simplestore will be completed, It supports almost all CMP 2 features at this time, but not well tested. Then you use simplestore + ARMI you dont need "remote interface", "Home interface","Value Object", "Bussines Delegate", "Local interface" ... . Any class class or interface can be persitent,distributable (secure and transactional is the next step) Hello anyone who's out there, I have an 'issue' that is rearing its head again and wld like to get anyones take on it. It concerns beans db and the lack (or maybe not) of a kinda jakarta proj/framework like struts, but addresses the back end. I know, there's EJB, etc... But, after working on EJB and non-EJB projects, I'm not convinved EJB is any more scalable or distributable than a good implementation of data aware beans - or something along those lines. I helped design a quite popular, big air travel site that took a non-EJB approach and worked well and scaled across 15 Sun boxes without a hitch. However, the implementation was a little complex and now that I'm working on another project, I'd like to have the same thing at a simpler level. So I guess I'm just kinda saying hi to the Commons proj and trying to see if anyone has thought about this issue. Especially since there is no Jakarta sub-project or Commons portion addressing this issue. Thanks and hi, - Jason -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This message was sent using DELFI MailMan - http://mailman.delfi.lt/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ALTRMI]-PATCH JNDI interface for Altrmi clients
Vinay, Paul, Did some prelim' JNDI bridge work for client-side lookup's and listing. skip/ Comments ?? I am over the moon I will put it in now! - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ALTRMI]-PATCH JNDI interface for Altrmi clients
Vinay, Did some prelim' JNDI bridge work for client-side lookup's and listing. Yes it is good stuff. I have committed it. Some small changes : 1) names of clases have be prefixed with Default. Why? EOB is likely to re-implement to allow internal VM lookup when the client thinks it is doing an external socket lookup (the holy grail). 2) 'supportedstreams' is static so has gone uppercase and final 3) your name has replaced mine as auther of the smaller class, as i did nothing really. Thoughts.. 1) I hate the env.put() business of JNDI. Should we also provide a helper factory (optional use) that will make an InitialContext for comon types of transport? It would be a non-standard way of making an initial context but many people do this anyway in their code. 2) The URL naming scheme for JNDI is very different to the colon delimited design that I have started in InterfaceLookupFactory. Should we change that to look more like JNDI ? 3) Tests. I think some of the tests should be changed to use JNDI for the lookup. Not all, as we should show people that they have options... Your thoughts? - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ARMI] ProxyGenrator
Juozas, Thanks for your continued thinking on this dude. Hi, ProxyGeneratorImpl and ClientClassAltrmiFactory use diferent ClassLoaders . We need to call generate in ClientClassAltrmiFactory not in ants task. I see BCEL is not very useful for ARMI if we are going to support only interfaces. skip/ I don't think that java.lang.reflect.Proxy is good enough for us. Why? 1) A scripting env like the excellent BeanShell cannot query the exposed methods and invoke them. 2) As we are not delegating immediately to a ral impl, we cannot have a single catch/throws block that suits all scenarios. If it were not for that it would be a good solution. BCEL almost certainly is (one of) the right tools to dynamic make proxies, the problem is it is Brain-Surgery to use. Anyone that can actually use it to make a proxy of the type we find easy via our javac route would be a god. I dream of a bytecode generator that allows me some natural java-like construction : JMethod ap = new JMethod(actionPerformed); ap.addArg(event, ActionEvent.class); ap.setVoidReturn(); // maybe this a default. InstructionList il = ap.getInstructionList(); Var txtVar = new NewVar(String,txt); ir.add(new JInstruction(txtVar, event,toString)); ir.add(new JInstruction(System.out, println, txtVar)); ap.generate(); Regards, - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ALTRMI]-PATCH DefaultMethodInvocationHandler,TestInterface*,SocketServerTest
Vinay,
Paul,
The referenceID that is generated from within
DefaultMethodInvocationHandler must be class level
variable.
Done.
The modified Testcases (I have done this excercise
with only SocketServerTest , if you say I can do the
same with other publish methods too)
for the same also attached along with the new facade
TestInterface3 (+impl)
I have applied these but not committed them. My feeling is that
TestInterface2 is exactly the same as TestInterface3 and offers nothing
new by way of tests. It will complicate a person's view of AltRMI if
they are trying to understand it via its tests. If we add tests, they
should be for difficult usecases, not clones of existing tests.. What
do you think?
- Paul
*PATCH**
Index: DefaultMethodInvocationHandler.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/server/impl/DefaultMethodInvocationHandler.java,v
retrieving revision 1.3
diff -r1.3 DefaultMethodInvocationHandler.java
48c48
private int mNextReference = 1;
---
private static int mNextReference = 1;
130d129
150a150
*PATCH**
Index: TestInterfaceImpl.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/test/TestInterfaceImpl.java,v
retrieving revision 1.4
diff -r1.4 TestInterfaceImpl.java
29a30
Vector ti3Holder = new Vector();
137a139,156
/**
* Method makeTestInterface3
*
*
* @param thingName
*
* @return
*
*/
public TestInterface3 makeTestInterface3(String
thingName) {
TestInterface3 ti3 = new
TestInterface3Impl(thingName);
ti3Holder.add(ti3);
return ti3;
}
195a215,234
}
return retVal;
}
/**
* Method getTestInterface3s
*
*
* @return
*
*/
public TestInterface3[] getTestInterface3s() {
TestInterface3[] retVal = new
TestInterface3[ti3Holder.size()];
for (int i = 0; i ti3Holder.size(); i++) {
TestInterface3 interface3 =
(TestInterface3) ti3Holder.elementAt(i);
retVal[i] = interface3;
*
Index: TestInterface.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/test/TestInterface.java,v
retrieving revision 1.4
diff -r1.4 TestInterface.java
100a101,111
* Method makeTestInterface3
*
*
* @param thingName
*
* @return
*
*/
TestInterface3 makeTestInterface3(String
thingName);
/**
127a139,147
/**
* Method getTestInterface3s
*
*
* @return
*
*/
TestInterface3[] getTestInterface3s();
***
cvs -q diff TestClient.java (in directory
C:\jcommons\cvs\jakarta-commons-sandbox\altrmi\src\java\org\apache\commons\altrmi\test)
Index: TestClient.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/test/TestClient.java,v
retrieving revision 1.5
diff -r1.5 TestClient.java
92a93,107
System.out.println(CLT: Test Another Facade);
TestInterface3 ti3One =
ti.makeTestInterface3(One3);
TestInterface3 ti3Two =
ti.makeTestInterface3(Two3);
System.out.println(CLT: One name = ' +
ti3One.getName3() + ');
System.out.println(CLT: Two name = ' +
ti3Two.getName3() + ');
TestInterface3[] ti3s = ti.getTestInterface3s();
for (int i = 0; i ti3s.length; i++) {
TestInterface3 ti3 = ti3s[i];
System.out.println(CLT: .. name[+i+] = ' +
ti3s[i].getName3() + ');
}
***
cvs -q diff SocketServerTest.java (in directory
C:\jcommons\cvs\jakarta-commons-sandbox\altrmi\src\java\org\apache\commons\altrmi\test)
Index: SocketServerTest.java
===
RCS file:
/home/cvspublic/jakarta-commons-sandbox/altrmi/src/java/org/apache/commons/altrmi/test/SocketServerTest.java,v
retrieving revision 1.8
diff -r1.8 SocketServerTest.java
66c66
as.publish(ti, Hello, new
PublicationDescription(TestInterface.class,
TestInterface2.class));
---
as.publish(ti, Hello, new
PublicationDescription(TestInterface.class,new
Class[]{TestInterface2.class,TestInterface3.class}));
***
cvs -q diff tests.xml (in directory
Re: [ALTRMI]-PATCH tests.xml
Vinay, Applied. Cheers dude. - Paul a typo cvs -q diff tests.xml (in directory C:\jcommons\cvs\jakarta-commons-sandbox\altrmi) Index: tests.xml === RCS file: /home/cvspublic/jakarta-commons-sandbox/altrmi/tests.xml,v retrieving revision 1.7 diff -r1.7 tests.xml 263c263 java classname=org.apache.commons.altrmi.test.DirectTestC fork=true --- java classname=org.apache.commons.altrmi.test.DirectTest fork=true 265c265 arg value=S/ --- arg value=C/ __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [AltRMI] What is the client/server connection life cycle?
Alvin, Hi, I think there is no ready-made here to increase the Ping duration. But one can do (for now) stop the pinger by doing something like: HostContext.getInvocationHandler().close() . Checkout the impl'n: *.altrmi.client.AbstractClientInvocationHandler.close() method ... What Viany says is true. But you have another option - you can if you want replace the DefaultConnectionPinger with PerpetualConnectionPinger or one that you write yourself in your codebase. It is designed to be settable. Maybe as you mentioned rightly , This should be implemented at each ConcreteInvocationHandler level too so that they can also close/release the socket connections to the server. A transport that establishes new connections per invocation ? I think that could work but be amazingly slow. Is not the proposition that it is some sort of thread sharing solution on the server side. A few other teams have done this sort of work on sockets at Apache, I'll see what code can be stolen.. How does the client indicate that there are no more requests for a long time [ie: waiting for the user's next command]? At the moment, the client does nothing proactive to say that the connection is idle. I am sure we could patch into the pinging mechanism so that the server could note that is the 20th ping without real method request. We are thinking about our distributed garbage collection needs. That is, when a client has truly finished with a proxy on the client side it is dropped by AltRMI on that side too and then communicated back to the server that it is no longer in use by that client. This could be done by something that is working like the pinger, in that periodically a weak hash map is perused looking for dead entries, elements are then trimmed from the map and reported as such to the server (or reported then trimmed). Maybe the last issue here is that we are still evolving AltRMI. We are pleased to a see others using it, but you must be aware that we have not tested this for bullet-proof-ness. That said we would welcome ideas, patches and even involvement from interested parties such as yourself. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [GUMP] Build Failure - altrmi
Ted [javac] import org.beepcore.beep.core.BEEPException; [javac] ^ Thanks dude, but I cannot understand why GUMP is flagging this. The dependant jar was booked in too and implicated in the build file. - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [AltRMI] (PATCH) BEEP wire
Vinay, Committed dude. When you next do a zip of source for me, can you leave out the cvs dirs ;-) Cheers dude :-) Hi Paul, Presenting the BEEP transport layer for AltRMI NEW PACKAGES: org.apache.commons.altrmi.client.impl.beep.* org.apache.commons.altrmi.server.impl.beep.* For now I have built an independent test suite(BeepClient/ServerTest), but I guess this can be merged onto SocketClient/ServerTest suite too Ant script puts the /lib folder into the classpath , and thats where the beep library (beepcore.jar) xerces wud go .. (Haven't attached the libraries here though .) tests2.xml have been updated with the 'beep-serve' and 'beep-client' targets too .. (This time I have NO batch files :-)) ) he he :-) We can benchmark it with Socket layer too. (It might performs well too compared to the '2 socket connection' approach when callbacks come into picture..) I see that you have a complete BEEP Factory and HostContext. That's a lot of work you have done. Some reading for me to do later! Question for others : If we include a BSD licensed jar (to compile against and resitribute) do we have to include it's license too... or just credit the origin. Regards, - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [AltRMI] multiplexing over single connection
Vinay,
Paul,
So would the right place to export an Object
from an API standpoint be :
AltrmiFactory.exposeObject(Object o);
You mean in the context of BEEP and the layer it represents inside AltRMI ?
I don't quite understand what you are asking here
AltrmiFactory is a client-side class, you would not call anythin on it
to publish (exposeObject is publishig right?).
BEEP would be used to allow us to have listeners straddling two VMs.
Consider the well understood PropertyChangeListener.
Server side :
interface XyzService {
void addListener(PropertyChangeListener pcl);
}
Client side :
class MyClient implements PropertyChangeListener {
XyzService xyzService;
public MyClient() {
xyzService = lookup( // via AltRMI
xyzService.addListener(this);
}
public void propertyChange(PropertyChangeEvent evt) {
System.out.println(Server has performed callback - + evt.toString());
}
}
What we see there is the client reaching out to the server as usual
(lookup), but then registering itself as a suitable listener.
Completely asynchronously, the server can call the applicable method on
the client, even if there is TCP/IP in the way. We need at least two
channels open to do this. One (as we have now) to allow the client to
invoke methods on the server and the second to allow async invokation of
methods on the client from the server.
- Paul
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[AltRMI] Initial design for FactoryFactory
Vinay, Related to our need for a) JNDI lookup and b) server redirection Take a look org.apache.commons.altrmi.client.AltrmiFactoryFactory. A default impl of that interface could have a set of registered 'providers' that could could construct or reuse an AltrmiFactory for a given factory-string. Those factory strings could be like: altrmi:object-stream:hostname:1234 altrmi:custom-stream:hostname: altrmi:rmi:hostname The default impl of AltrmiFactoryFactory would use the existing AltrmiFactory impls, an alternate container like EOB could use it's own. Thoughts? - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [AltRMI] multiplexing over single connection
Vinay,
Paul,
I was aiming along the lines
of UnicastRemoteObject.exportObject(Remote obj) .
For the EventNotifier example I was trying
to come with ,
the Subscriber exports itself
and passes the reference of it to the Server.
Subscriber:
// SubscriberInterface.java
public interface SubscriberInterface
extends java.rmi.Remote {
void inform(Event event) throws
java.rmi.RemoteException;
}
Hey dude, you're scaring me with RMI interfaces!
And ConcreteSubscriber does something like
ConcreteSub()
{
UnicastRemoteObject.exportObject(this);
}
So what you are proposing with PropertyChangeListeners
It was just an example of a use of call-back.
would also work in my scenario too since there I
would be passing the PropertyChangeListener
objs to the server rather than a custom
Subscriber_stub.
But this was the direction I was coming from ...
comments.?
Publish/Subscriber heh? I think you know more about where you want to
go with this than I do.
Pub/Sub is just an fancy name for callbacks not so? Are we not talking
about the same thing?
- Paul
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[AltRMI] Changes to publication API
Folks, As per Vinay's suggestion of a couple of weeks ago, a PublicationDescription object is now passed in to the one of two paublish(..) methods rather than have this overloaded six or so times. - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [AltRMI] multiplexing over single connection
Vinay, Yes you are right BEEP looks better. There is a BSD impl on SF :- http://sourceforge.net/projects/beepcore-java/ I don't think it is an issue for Request/Reply as it is a layer between AltrmiInvocationHandler and the true streaming mechanism... - Paul Hi, dghmux seems kewl, However BEEP addresses this in a much broader and *standard* compliant way . It even has a tunnel 'profile' to take care of the NAT issues too . This might be viral to the Altrmi codebase as it might influence the way Request/Reply objects are sent across the wire ..(not sure though).. Any BEEP experts who can throw light here ?? Regards, V i n a y. --- Paul Hammant [EMAIL PROTECTED] wrote: Folks, To solve the callback feature for AltRMI This was the sourceforge project : http://dghmux-java.sourceforge.net/ It is LGPL which is OKish for Apache use. I kinda prefer two connections though, if the client opens both then there are no NAT problems. The OpenConnectionRequest class could be expanded to have a parameter that indicates server-is-listener or client-is-listener. Thoughts? - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [AltRMI] Event Notifier
Vinay, Anyways on another page , I feel it would be good exercise to have the Event Notifier pattern working over AltRMI transport, something along the lines of the same pattern over RMI .(ref http://www.javareport.com/html/from_pages/oldarticles.asp?ArticleID=132 ) This would neccessiate a form of callbacks to be made avaliable within the Altrmi realm. Maybe by keeping a Message-Loop Thread at the client-end Open for receipt of REQUEST messages back from the server. Essentially implying REQUEST messages can flow from the server to the client too :-) Yup this would be cool. The problem as I see is that we would have to have a second connection open. I am sure smarter people could get duplex working over one connection usine notify/wait etc, but I can't see the solution without two connections (one for the server to listen on and one for the client to listen on). Does anyone have any experience on duplex over one socket connection? There was also that (LGPL) project at sourceforge that could multiplex any traffic over one connection. It was very good in that it could shove data before it was even picked up at the other end. Not so relevent to us as we have multiple transports types... This can again form one those so called (non-junit) *test* cases which actually does more than *testing*. He he. - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[AltRMI] Two way weak hashmap for distributed garbage collection
Folks, I have searched for, but cannot find, a posting in this mail list some while ago that offered a two way hashmap. We think we might be able to use it for distributed garbage collection. Background : AltRMI creates a clientside stub for each server side facade reference in use. On the client side this is two hash maps. One allowing lookup of instance based on reference key (a Long at the moment), and one that allows the reverse lookup. I'd like to move to some better design that will allow the client side garbage collector (I am on about the one built into the JVM) to allow purges from the map. Clearly we need to move to an impl based on Weak References and also to an impl that is more efficient that to mutually pointing hashmaps. Once that purging map were in place the clientside factory could invisibly communicate back to the server which references were no longer used by a session. Thus in some stuttering nature, the distributed garbage collection works. Does anyone know where that hash map impl is? Did it get combined into commons-collections? - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [AltRMI] Two way weak hashmap for distributed garbage collection
Juozas, Thanks but I have had an on/off relationshp with finalize() from 1998 onwards. Sun even give advice on why it should not be used. It is a WeakReference soltution I am looing for. - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [AltRMI] Two way weak hashmap for distributed garbage collection
Juozas, I 99% sure RMI distributed GC implementation baset on finalize(), Not in 1.3.1 nor in 1.4 (I have checked). There are some 20 other uses though. This bug http://developer.java.sun.com/developer/bugParade/bugs/4148454.html and others show why finalize() is dodgy. - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [AltRMI] Pass-by-reference redirection
Vinay, altrmi:transport-type:host-details:service-name:reference-id *Redirection* would also imply a protocol(REQUEST obj maybe ) which allows ServerB to tell ServerA to register a remote object for him . I was thinking of a solution for the immedate need (refer EOB people example) : Server 1 (Bean 1) Address Factory, Manages Address Server 2 (Bean 2) People Factory, Manages People and their addresses Client 1 (Bean 3) : Gets Bean1, makes a person. Gets Bean2 makes an address. For its person remote ref, on bean1 sets the address to that made above. In this case the ref the client has a problem in that it is trying to pass a remote ref from server 1 to server 2. Of course the client knows nothing of this. Anyway, to summarise, the two servers have instances already, it is just that for one setAddress method in server 2, the adress being used is also from a remote reference. This is the area that EJB steps into keys for to solve. Maybe this goal (to have a 100% reference solution) is impossible. So I don't think the immedaite need is for ServerA to register a remote object for him , but for serverA to tell server B that it has a remote inst that is being held for it . For the immediate need anyway. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons/Avalon [was Re: [Logging] [VOTE] Commons Logging 1.0 Release]
Sam, Another perspective is that inter subproject sharing at a granularity lower than the subproject has rarely been successful. Things originally identified as reusable components often ended up getting dependencies on ever increasing portions of the subproject. At the time commons was created, Avalon was notorious for changing interfaces without even so much as a moments notice. The rationalle given was that Avalon was still in alpha - interminably so. I am not sure that is so correct. There have been refactorings, but old abstractions were kept as deprecated for quite while. The only way a developer who dependended on the component could get a say in the matter was to become a committer in the subproject at large. In the case of Avalon, this meant becoming a committer to the entire framework: jakarta-avalon, jakarta-avalon-testlet, jakarta-avalon-logkit, jakarta-avalon-phoenix, jakarta-avalon-cornerstone, jakarta-avalon-excalibur, and jakarta-avalon-site. In other words, they were required to follow an absurd rule allows people to vote on something they dont use/develope and never plant to use/develope. With respect, all the above are a single commit right. I could be wrong on jakarta-avalon-site through, but that is not relevant to this discussion. Avalon people willfully accomodate the needs of JAMES and Cocoon people inside Apache and plenty of those interested outside Apache. We frequently reach out to other teams in very polite, respectful and concilliatory terms. So commons was created. It is explicitly designed as a place for people who play well with others. And after some initial growing pains appears to be working. - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons/Avalon [was Re: [Logging] [VOTE] Commons Logging 1.0 Release]
Folks, We frequently reach out to other teams in very polite, respectful and concilliatory terms. Time for a little commit relief: My name is Avalon Server Famework, Commander of the Servers of Java, General of the component Legions, loyal servant to the true emperor, Inversion of Control. Father to a lifecycled bean, husband to a lifecycled container. And I will have my vengeance, on this main() or the next. Yup a paraphrased Gladiator quote for some fun. The central idea is that apps that are only launchable by main() are not very embeddable in others. It is also a clearly a reminder of one of the main design patterns behind Avalon - Inversion of Control. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] for list() functionality for AltRMI
Vinay, Thanks for these. I have applied them and they work well. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [AltRMI] New Direct-Marshalled transport type
Juozas,
skip
But I don't know how to handle By Value.
void myMethod( MyInterfaceType mt ){
mt.setSomething(X);//Don't understand how to handle this ( is
X set on copy of Object ? )
}
X will be a copy of the object if pass by value or over the wire.
I'm not quite sure what your asking here.
Yes, communication is my problem :(
I try to see framework or API as user .
I see two problems in transparence. Distributed and Persistent
objects have problem with
Fatal Errors like Connection is lost and By Value then users
code tries to set something on copy of object.
Transparent objects doe's not implement any Tag Interface and doe's
not throw checked Exceptions
specific for way they are marshaled.
//
Problem 1 :
users code (Fatal Errors specific for framework implementation )
void myMethodUsesTransparentObject( Transparent transparent ){
try{
transaction.begin();
transparent.doSometing();//throws some App Exception
transparent.setSomething();
.
transaction.commit();
}catch(SomeCheckedAppException sce){
log(sce);
transaction.rollback();
}
// I forgot to handle Connection is lost and compiler says
nothing.
// My transaction is incomplete and it is very possible I have a
Lock forever on some resource.
// It can be impossible to find this bug for user. We need
solution, I don't have it.
For the connection failures issue, the client-side user is informed via
a AltrmiInvocationException. This can be caught in a number of places.
My preference would be in a single nexus :
void initialize() {
try {
// method calls
}catch ( AltrmiInvocationException ae ) {
if (transaction != null) { transaction.rolback(); }
getLogger().error(blah,ae);
throw ae; // or a new one.
}catch (Throwable) {
// something similar.
}
}
Of course with a bean container a policy can be set for a bean, so
that predictable actions take place.
}
//
Problem 2 :
User calls my transparent objects he don't know marshaling stuff,
implements callbacks sets Context ... .
He knows :
virtual void my_cpp_method( transparent object )=0;// By Value
irtual void my_cpp_method1( transparent object )=0;// By Reference
procedure MyPascalProcedure( var aObject : TTransparent ) virtual
abstract; (* Always By Reference *)
public void myJAVAMethod(Transparent transparent);// sometimes By
value ? Transparent has no Tag interface
User knows usual stuff, and Transparence must become usual.
In this case, the class containing the method myJAVAMethod() is a facade
and proxyed to an equivalent on the server. You are worried about
Transparent class and how AltRMI knows whether it is pas by value or
by reference (a facade). Easy, at time of publication, the developer
designates a number of additional interfaces as facades rather than pass
by value. If it is known that Transparent has setter functions that
could cause problems make it an addition facade. There is no need for a
Tag (Marker?) interface. The downside is that Transparent.class needs
to be an interface with one or more impls. But then that is the same
rule taht RMI has for solving the same issue.
///
Very possible to train users, write books, documentation, I don't know
is it solution or not.
I have no solution for this two problems.
It is because I trying to think as user, I must think about my team it
is my job.
I like transparence, but I think it can kill users project if will not
solve my problems.
I hope I have addressed your concerns Juazos. I think you know yourself
that you're little hard to understand. Sadly so I am, but I don't have
the excuse of having English as a first language ;-)
Regards,
- Paul
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [AltRMI] New Direct-Marshalled transport type
Juozas, Yes I see it is possible to solve problems this kind. I need transparent distributed objects in my projects, It is because I speak a lot about ARMI. I am afraid this can be difficult to understand for my coworkers, but will fink a lot about this before next project. I think Transparent Persistence will be the first revolution in my company. :-) BTW. I am not kidding about ARMI over DCOM I have spend 2 year with this stuff ( ActiveX, win32, IUnknown, IDispatch , ..,Ole Automation, ) and I can help to implement this. I am not sure what you are proposing AltRMI having DCOM transport types? Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper's java compiler.
Geir, What we needed/need to do is have a JSR submitted for a compiler SPI (service provider interface). The current one is just an internal unpublished com.sun.x class -- there's no existing standard. Wanna start one? Indeed I do. I think it would help all around... Is there not a target of a dynamically invocable compiler or bytecode generator in JDK1.5 ? Regards, - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[AltRMI] New Direct-Marshalled transport type
Folks, I've coded another tranport type for AltRMI - Direct-Marshalled Here is a comparison of three similar AltRMI types: * Direct Marshalled Transport. - marshalling takes place. - instances passed by value between client and server may not be a mutually visible classloader. - does not need separate threads for client and server. * Direct Transport - no marshalling takes place in Direct Transport. - instances passed by value between client and server must be a mutually visible classloader. - does not need separate threads for client and server. * Piped Transport - marshalling takes place. - instances passed by value between client and server may not be a mutually visible classloader. - needs separate threads for client and server. I have coded it for Alt-EJB (now named Enterprise Object Broker and hosted on sourceforge and 10% coded). Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [AltRMI] New Direct-Marshalled transport type
Juozas,
It is very interesting, does somebody works on persistence ?
No yet. The example beans have no persistence. The idea is that the
developer chooses what type of persistence they need. File, Store,
JDBC, JDO.
I know this stuff like JTA, JAAS, JDO ... .
Thats good.
Commons-Store would be cool for re-use in EOB.
I work on persistence in the current project, I have plans to complete
it next weak.
Idea is like this : User defines some interfaces and optional
mappings. Container or application
Manages persistence and transactions , user defined interfaces can
be reused for Value Objects,Remote/Local ...
I will use simplestore for cache.
:-)
Do you need this kind of code ?
But I don't know how to handle By Value.
void myMethod( MyInterfaceType mt ){
mt.setSomething(X);//Don't understand how to handle this ( is X
set on copy of Object ? )
}
X will be a copy of the object if pass by value or over the wire. I'm
not quite sure what your asking here.
Consider :
interface StockPortfolio {
int getShareCount(String ticker);
void addToPortfolio(String ticker, shareCount);
void removeFromPortfolio(String ticker, shareCount);
String[] getStocksHeld();
}
class JDBCStockPortfilioImpl implements StockPortfolio {
// all those methods implemented like in classic entity bean
}
class CommonsStoreStockPortfolioImpl extends
org.apache.commons.simplestoreSynchronizedStore implements StockPortfolio {
// or 'has a' in stead of 'extends' as it is final.
// all those methods implemented and routing through to the store
methods.
}
I have coded it for Alt-EJB (now named Enterprise Object Broker and
hosted on sourceforge and 10% coded).
I like this name :)
In spoken form - 'Yob'
It is a name that Gerhard and I though up after discussing over a couple
of days
- Paul
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AltRMI Tasks if anyone want to take them
Sam, As near I I can tell, the charter of commons in this area is identical to the charter of avalon. A committer to avalon-any is a committer to avalon-all. I believe that I am even a committer to myrmidon. Peter has a point in that in commons there are 30-odd comunities. We all have too little time to actually fully appraise anything, there is naturely a tendancy to veto anything that /sounds/ daft. Avalon has four communities, and generally people don't vote of the community they are not active in. Thus people let me get on with insane stuff in Cornerstone ;-) - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AltRMI Tasks if anyone want to take them
Sam, Peter has a point in that in commons there are 30-odd comunities. We all have too little time to actually fully appraise anything, there is naturely a tendancy to veto anything that /sounds/ daft. Is this a hypothetical assumption? Or have you experienced it as a problem here? Bit of both. Also as much of a statement of self. I tend not to look at all the other commons projects, though I have read all the proposals. I'm polite enough to stay out of those that I'm not involved with. Maybe it is not that big a deal - the scenario where nay sayers veto some decisions from a position of ignorance. Not a big deal, in that a re-group re-propose can occur. - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AltRMI - Proposal request for help
James,
The first thing to do is get it from CVS, compile and run it as per the
README.
Done. Nice, I'm impressed. Am digesting in more detail now.
Very minor comment, how about renaming altrmi-tests.xml to be just
tests.xml. It saves some typing when running stuff. Maybe it could set a new
trend; build.xml is for building stuff and tests.xml is for various test
programs.
Rename : will do. It is separate primarily because there is an ant task
created which cannot be used in the build file that creates it :-(
As a complete aside, I'm interested in getting together at some point a kind
of 'distributed JUnit' thing so that (say) client and server processes can
be started (or even much more complex networks of clients and servers on a
variety of machines platforms) and the collection of processes are
started, coordinated and ran as a single JUnit test case. Then for example,
all the pairs of clients and servers could all be run as part of a single
JUnit test suite. I'm thinking Ant is the way to start processes (just like
you're doing with altrmi-tests.xml) then some kind of JUnit-ish framework on
top doing the distribution coordination. Anyways, back to the matter at
hand...
After that look at the classes in the test package to see how,
from the user's point of view, it is used. I think you're brave taking
on a JMS transport, but then perhaps if you know it well it might be
quite easy.
I know JMS well, I've used it quite a bit. Several years ago I even
developed a JMS provider so it shouldn't be too hard. More later...
AltRMI's magic (not) is that it transports method calls in
serializable classes. There are quite a few communicated through a
simple, single API...
AltrmiReply handleInvocation(AltrmiRequest request);
Consider...
class MethodRequest extends AltrmiRequest {
String methodSignature;
Object[] args;
Long referenceID;
}
class MethodReply extends AltrmiReply{
Object replyObj;
}
.. (and a few others). The handleInvocation() method, in the impls so
far, can tranport itself over RMI, over plain sockets (using
objectstreams and a custom solution). There are also very useful impls
that transport/marshall within one JVM ('Piped' and 'Direct').
Looks cool.
Another minor comment, some of the core APIs of AltRMI use Altrmi in the
interface names; how about removing them, since afterall the
classes/interfaces are in altrmi packages.
True. There is always a compromise between namespace on classnames. My
feeling is that Connection Component and Document are very over
used as class names and should definately be prefixed for futher
definitions. (Intellij's IDEA can be too suggestive for those). In
short yes, Perhaps some of the Altrmi prefixes for class names should go.
e.g.
AltrmiInvocationHandler - InvocationHandler.
Vote against as that's already used in the JDK.
AltrmiRequest - Request
No, because it's too simple a word. It was the firsat thing to be
renamed from Request to AltrmiRequest.
There are 20 others that are good candidates though you ust chose a
couple that I'd resist on. :-)
It just makes code that little bit easier to understand, and there's always
fully qualified class names if ever there's a naming conflict issue.
If the imports are specific (as per Apache rules) then the possibility
is greatly diminished, but still possible. I'm motivated (for those
two) by untellisense in IDEs
Just out of interest, have you taking a look at JAX-RPC? It has a similar
model which might give you some good ideas. From last time I looked the API
of JAX-RPC looked like the transport was agnostic.
Will do.
For JMS, if it can transport classes like those above via an interface
like that above, then it is fine. I'll have to read more.
Specifically, I'm not sure how the asynchronous side of things will work.
Just to save a bit of reading... JMS can send and receive a variety of
different kinds of Message objects. The core Message interface provides
various standard headers as well as allowing user defined headers
(properties) on messages. Then there are various derivations of the core
Message interface to provide various kinds of message body such as
TextMessage where the body is a String, ObjectMessage where the body is a
Serializable object, MapMessage where the body is somewhat like a Map
(though unfortunately doesn't use a Java 2 Map interface) and some binary
messages like BytesMessage and StreamMessage.
Both synchronous and asynchronous communication models can be implemented
quite straightforwardly, receiving supports push and pull models. Also JMS
supports queue semantics, only one consumer receives the message (similar to
connection-less point to point) and publish/subscribe semantics (all
consumers interested receive a copy of the message). Finally JMS provides a
variety of Quality of Services such as persistent messages, XA compliance
etc.
So I would think it should be fairly straightforward to implement AltRMI in
Re: AltRMI load balanced requets from client to server(s)
James, Just thought I'd mention, using JMS Queues is a great way of implementing load balancing server clusters. If servers fail messages are rerouted to other working servers. Messages can be stored persistently for full fault tolerance so that if there are no servers running messages are not lost and things will recover properly when servers are restarted. Though this requires a JMS provider though - and a decent one costs money these days. Yup those features or JMS would be good. Also a JNDI lookup that could return a different server each time would be cool. One design principle behind AltRMI is the rigid separation of interface, abstract parent classes and concrete impl. With this a completely standalone AltRMI client should be able to collaborate with a remote server who's functionality has been rewritten/extended/reimplemented for various reasons. All that is comon to all is in the common package. The point is that there could be two or three impls of the load balancing client factory :-) They may or may not share code. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AltRMI performance figures
Juozas, Don't forget Alternative SomethingUsual means very negative for integrators :). It is kind of bad for name. I know dude, I'm coming round to your idea of something with the word transparent in it. TRMI (Transparent RMI) etc. - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AltRMI load balanced requets from client to server(s)
Incze, Oe Mon, Jan 21, 2002 at 09:57:47AM +, Paul Hammant wrote: Juozas, It can be useful for FAQ: 1. Is it plans to implement groups ? ( I am not sure but I think http://www.javagroups.com is used to implement cluster in JBoss 3 ) http://dghmux-java.sourceforge.net/ looks interesting too. 2. Is it plans to implement ARMI over DCOM. ( I saw some bridge implementation, but do not remember link at this time ) Interesting. There is an excellent product called JIntegra that exposes objects to DCOM introspection/invocation. Regards, - Paul H Altough not a knoledgable person in the are but have read a good article on the jawin open source Java/COM interoperability project. Here is an article on it: http://www.onjava.com/pub/a/onjava/2001/11/14/jawin.html with link to the project. The author maintains a resource page to similar open source and commercial products, too. It would be great if we could convince the author to bring JarWin to Apache yes? Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AltRMI Tasks if anyone want to take them
Sam, .. as long as it is black. ;-) Excellent reply. It touches on one of the significant (IMHO) differences between commons and avalon. It is a different point than the one I was going after (the difference between an auto parts store and the parts counter at a car dealership), but a good point nevertheless. OK, a quesiton. Commons is about beanlike classes that have multiple reuse in servers (though client is not precluded). Avalon-Excalibur is about reusable components that fit the IoC pattern, and in the context of Avalon are decorated at startup from XML configuration, to do this quite a few of them site of Avalon-Framework's componenet abstractions. That a (my) simple view. I've tried to code AltRMI so that is usable in the context of an XML configurable component env like Avalon-Phoenix. It's quite easy if you boredom-alert rigidly separate interface and impl /boredom-alert. Of course I could have got it quite wrong... Thus in my view AltRMI is beanlike but because of it's interface/impl separation, it can fit the Avalon-Phoenix env too. I can't help feeling that I have forgotten about the needs of my Excalibur buddies. Regards, - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AltRMI Tasks if anyone want to take them
Sam Parse error. Question not found. :-P Indeed, and I have forgotten the question, though it seemed amazingly relvant at the time... I'd love to see more components which separate interface and implementation. Ideally, they could have multiple interfaces. One per framework. Each sharing a common(s) implementation. Ahh, you take the pee.. :-) Seriously, I am quite happy with wrapping AltRMI is wrapped and represented as a phoenix component. As long as a component has little static usage, does not bind itself to the command line or a File bound properties file for configuration, or have environmental var needs, then it is wrappable. (it is beanlike as I say). - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AltRMI load balanced requets from client to server(s)
Folks, I'm starting work on a HostContext that would allow a single client to actually hit multple servers for method invocations. The following scenarios would be possible: 1) Client opens a connection with a random* server and continues to route methods calls to that server 2) All method calls would hit a random* server (no stickiness) * Secondly when we say random, there are likely to be other implementations that are useful: a) Some sort of querying load capability solution. One server is asked which of others in its fedaration should be hit with requests. b) Simple rotating load balancer, first connection uses server0, next server1 etc. What is would be considered the most important to do? Would there be anything else that would be useful at this stage? Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[AltRMI] More use of
Folks,
I've upgraded the 'helloworld' demo in Avalon to also accept
setGreeting() calls over AltRMI. See the posting in Avalon-dev's maillist.
I've also updated the BeanShell fork I maintain at
http://jesktopapps.sourceforge.net/ so that it can similarly poke any
method published by AltRMI anywhere. arLookup(..) is the .bsh script.
Here it is:
bsh.help.arLookup = usage: arLookup(host, port, name), returns object;
/*
By Paul Hammant : Specifically for Jesktop
*/
Object arLookup(String host, int port, String name) {
org.apache.commons.altrmi.client.AltrmiFactory af = new
org.apache.commons.altrmi.client.impl.ServerClassAltrmiFactory();
af.setHostContext(new
org.apache.commons.altrmi.client.impl.socket.SocketObjectStreamHostContext(host,
port));
return af.lookup(name, true);
}
Just three lines of code :-) Typical use below (in Beanshell's console):
hws = arLookup(127.0.0.1,8666,helloworld);
hws.setGreeting(AltRMI rocks);
Regards,
- Paul H
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AltRMI - Proposal request for help
.
9) Event API
- For suspensions, abnormal ends of connection etc, there is a listener
that can be set that will allow actions to be taken. Abnormally
terminated connections will by default try to be reconnected, the
listener can decide if, how many, and how often the retries occur.
10) Unpublishable and republishable API
- The server is able to unpublish a service. In conjuction with
suspend()/resume() a service can be republished, upgraded etc
whilst in use, or just offlined.
11) Startable API for Server
- The server implements and acts upon start() and stop() methods.
12) No just pass by value.
- AltRMI started life as 'pass by value' only. In now supports return
types and parameters wrapped in another AltRMI Facade.
13) No duplicate instances.
- If you call Person p = getPerson(Fred) twice you will get the same
instance on the client side is it is the same instance on the server
side.
Limitations:
1) Use in EJB
- This is not of any use for EJB Home/Remote interfaces. The container
maker chooses the transport for use that container, not the bean coder.
This is intended for other client server solutions. Beside RMI over
IIOP
is Sun specified.
Todo:
1) Other transports
- SOAP, CORBA (with WDSL IDL generation steps)
- Other RMI (over IIOP, over HTTP)
- Custom, socket protocol
- JMS
2) BCEL for generated proxy class.
- The current impl writes java source then compiles it. We could do this
inline with BCEL. This as an heavier, but more design perfect
alternative to the current server side impl.
- BCEL is really difficult to use if you are not skilled in it!!
3) Client and Server code for secure conversations.
4) Authentication and Authorisation on lookup(..).
Initial committers:
Paul Hammant (hammant)
--
Example Generated Proxy class. Not for editing, not normally
for user viewing. A step similar to rmic.
--
public final class AltrmiGeneratedHello_Main implements
org.apache.commons.altrmi.test.TestInterface {
private transient
org.apache.commons.altrmi.client.impl.BaseServedObject mBaseServedObject;
public AltrmiGeneratedHello_Main
(org.apache.commons.altrmi.client.impl.BaseServedObject baseServedObject) {
mBaseServedObject = baseServedObject;
}
public void hello (java.lang.String v0) {
Object[] args = new Object[1];
args[0] = v0;
try {
mBaseServedObject.altrmiProcessVoidRequest(hello(java.lang.String),args);
} catch (Throwable t) {
if (t instanceof RuntimeException) {
throw (RuntimeException) t;
} else if (t instanceof Error) {
throw (Error) t;
} else {
throw new
org.apache.commons.altrmi.common.AltrmiInvocationException(Should never
get here + t.getMessage());
}
}
}
public boolean hello3 (short v0) throws
java.beans.PropertyVetoException, java.io.IOException{
Object[] args = new Object[1];
args[0] = new Short(v0);
try {
Object retVal =
mBaseServedObject.altrmiProcessObjectRequest(hello3(short),args);
return ((Boolean) retVal).booleanValue();
} catch (Throwable t) {
if (t instanceof java.beans.PropertyVetoException) {
throw (java.beans.PropertyVetoException) t;
} else if (t instanceof java.io.IOException) {
throw (java.io.IOException) t;
} else if (t instanceof RuntimeException) {
throw (RuntimeException) t;
} else if (t instanceof Error) {
throw (Error) t;
} else {
throw new
org.apache.commons.altrmi.common.AltrmiInvocationException(Should never
get here + t.getMessage());
}
}
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: AltRMI - Proposal request for help
Robert, I wonder if there are any people in BCEL-land who'd be willing to volunteer to join you as initial committers? BCEL is very new to Apache and most of the many other BCEL using projects are still using the previous (non-apache) version. I think it will take some months before a community builds up around BCEL at Apache. The problem is that it worked perfectly before it came to Apache and one of the golden rules for people starting projects anywhere is that your user comunity has to have an itch for certain new features to have the incentive to become developers. It should be easy to code the BCEL stuff - I keep looking at it but am scared off by the assember type syntax that Java bytecode has forced on BCEL. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Update to Commons package approval guideline
+1 (though I am unsure whether I as yet qualify as a commons committer) Martin Cooper wrote: The current Commons guidelines require a positive super-majority vote of active subproject committers before a new package is accepted into Commons. Given the number of committers in Commons today, I believe that this is no longer tenable. Therefore I propose that we update item #17 of the guidelines to require majority approval, as defined in the Jakarta guidelines, before a package is accepted into Commons. The replacement text for item #17 would be as follows: - 17. New packages may be proposed to the Jakarta Commons mailing list. To be accepted, a package proposal must receive majority approval of the subproject committers. Proposals are to identify the rationale for the package, its scope, its interaction with other packages and products, the Commons resources, if any, to be created, the initial source from which the package is to be created, and the initial set of committers. 1. As stated in the Jakarta guidelines, an action requiring majority approval must receive at least 3 binding +1 votes and more +1 votes than -1 votes. - +1 from me. :-) -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Vote] ARMI to move
Some could argue that. Is that a -1 for you then? :-) Don't you need more active committers? -PH -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Vote] ARMI to move
So far we have one vote placed. I am pleased to say it is in favour of ARMI (probably to be repackaged as AltRMI) moving to regular Commons CVS. Anyone else case to cast a vote? Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [proposal] some store components for the commons-sandbox
Scott, +1 for the sandbox. Store seems like a perfectly usable component. Have you looked at what JAMES and Slide have. I think that also have store impls. JAMES uses a Store service that has multiple implementations. The particular implementation used is configured in XML. One of the impls uses Avalon-Cornerstone's Store, which itself is configurable in XML. It is all to do with the IoC pattern. JAMES and Cornerstone are Avalon-Phoenix based componements. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Vote] ARMI to move
Scott, Why not just altrmi? Yes, thats good enough. Cough cough, how about a vote on the migration? - Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ARMI mobilisation?
Juozas, snip I see no ARMI advantages. I am not stopping anyone useing RMI if they want to. I note in the proposal it is no good for EJB. It's other limitations are noted too. It does have advatages, just read the Proposal. I guess we (you and I) will never meet in the middle. I'll feel free to ignore your projects too, and look forward to your -1 when the time comes. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: ARMI mobilisation?
Folks, Any thoughts for ARMI (though it needs a rename as Async RMI already used). Is commons the place for it? Yes/No? Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ARMI mobilisation?
Commoners, I have pushed a working verision of ARMI into commons-scratchpad and anyone with Ant should be able to build and test it. To become a proper commons project what needs to happen? Normally Jakarta rules insist that a project has an active developer community behind it before it gets hosted at Apache. This is not the case for ARMI as it has been a solo effort so far. Is it as simple as a vote from Commons committers? Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New tool - armi - 'alternate to RMI'
Folks, Now coded is class definition transport. It is configurable in that the coder can choose whether this generated class resides on the server or client side. It works, but when the class is transported the subsequent invocations are about 8% slower (discounting the time taken to transport the class). This is perhaps because I have the proxy impl in a seperate classloader when retrieved. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New tool - armi - 'alternate to RMI'
James, I agree that RemoteException is a PITA; its unfortunate that a checked exception was used IMHO. It might be worth taking a closer look at the JAX-RPC stuff; maybe your ARMI idea might make more sense if there is a plugable protocol such that RMI, ARMI, JMS or SOAP could be used as the transport mechanism. There are two transports coded at the moment: 1) ObjectStream over plain sockets (same VM, different VMs or difffernt IP visible machines) 2) ObjectStream over Pipe (same VM) To do are: 3) RMI transport 4) direct (unmarshaled) transport 4) SOAP transport 5) JMS transport (I add this now you mention it). I'll do 3 4 today, but probably stop there for now. I'm still unclear whether I am getting a mandate in Commons or whether I should go back to Avalon with this. It is decidedly client/server - our original raison d'être. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New tool - armi - 'alternate to RMI'
It should be ready for a test run now, if anyone want to take it for a spin. The speeds as previously calculated were wrong. ARMI over RMI was slowest. Stream over Sockets was three times faster, Stream over Piped (in same VM) was 11 times faster and Direct (same VM) was 1000 times faster - though these are not all great comparisons. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Database Connection Pool
Randy, Could you please tell me where the document is on how to configure and start and access Avalon's connection pool. Wrong list and using my brain. Get Avalon (four projects) from CVS. Use Find in Files or equiv to find source containing ConnectionPool or just Pool for more fun. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: New tool - armi - 'alternate to RMI'
Christopher, You're not the only coder who thinks that way. :-) When I first started working with RMI, RE's really disappointed me, because my goal was to develop code that could work equally well whether it was going to run remotely or locally, allowing me to dynamically switch from distributed to single-machine behaviour. The way RMI is set up, however, I either have to write 2 versions, or accept crufted code if I am running on a single machine. I really like the armi proposal, but have one major problem with it, which is that EJB is developed around RMI and RE's, and I don't see anything in the spec that would make switching over possible, although I am open to the idea that I am missing something here. It's no longer a proposal. It is very nearly complete. I've coded a Piped transport (as well as socket) so we (Avalon team) could use it for in-VM transport for very complex classloading cases. WRT to EJB, I think the latest specs allow the dropping of the RemoteException on the method signatures (or was that not extending the Remote interface?). To be honest this is more useful to us that J2EE coders (who put up with loads of cr*p). If you were coding a general server (FTP, HTTP, Gopher. POP3 or SMTP etc) and wanted a remote admin capability then you would automatically use RMI these days. I am influenced greatly by SOAP. Or more particularly Glue which will publish any interface remotely without RE. If the esteemed Graham Glass can do it, then we can to. The transport is open, so bizarrely we could implement an RMI, SOAP or CORBA transport for ARMI too. The Server impl is open so that it can be replaced with a non factory version for bigger projects (like Avalon). There are some limitations, in that it wants to be limited to Serializable objects and primitives for return values and params, but hey the coder could be quite happy with that. I also does not mean that that could not be fixed later. Just my 1/4 byte And quite welcome. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Database Connection Pool
Randy Speh wrote: Thanks for the info. Would you mind telling me the differences between Avalon and Fulcrum/Commons. I just wasn't aware of Avalon for some reason. I've been submerged in Turbine, Torque, Fulcrum and Commons code. It is big. See http://jakarta.apache.org/avalon/ Commons has some overlap with Excalibur only. Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
New tool - armi - 'alternate to RMI'
Folks, I'm more usually found in the Avalon project at Jakarta. I have something that I have been writing that might be more at home here than there. It is a replacement for RMI that delivers on one design goal : Any interface can be published over the wire. It does not have to extend Remote or have RemoteException thrown left, right and centre. I appreciate that as many people love RemoteException as there are those that hate it. We do of course indicate this serious error state but with an extension of RuntimeException. The user of armi will have to be careful in their strategic handler code to have a catch clause for the exception, but it at least allows the developer how to handle it rather than forcing it to be handled everywhere (like RemoteException). The interface is published on the server : void publish(Object impl, String asName, Class[] interfacesToPublish) This forces of course a interface/impl seperation, but we're all doing that in this age right? On the client side, the developer has to do a lookup: Object lookup(ArmiHostContext hostContext, String named, Class[] exposingInterfaces) Such that the following could be done: ArmiHostContext arhc = new PlainSocketHostContext(myserver,1234); Log = (Log) ArmiFactory.getDefaultArmiFactrory().lookup(arhc, log-service, Log.class); The server side is handled automatically by the fact that the publish method is called. The client side needs some generated classes (that implement the interfaces) that will be build in a style similar to RMIC. It is about 70% done. And there will be some limitations (it leans towards simple, standard, serializable primitives and object types for params and return codes). Are you folks interested? Is Commons the best place? How is a decision made here? Regards, - Paul H -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
