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 d

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 - T

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 d

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 an

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-replat

Re: _Commons-Attributes_(sandbox)_and_Jon_Tirsén.

Finder 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 >

Re:_Commons-Attributes_(sandbox)_and_Jon_Tirsén.

; 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 w

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,

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.

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).

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 deployment

[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); } }

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 qu

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:

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 genera

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/Pr

[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

Re: [Altrmi] Callback iteration

=== >RCS file: >/home/cvspublic/jakarta-commons-sandbox/altrmi/tests.xml,v >retrieving revision 1.12 >diff -r1.12 tests.xml >141a142,150 > >> > >description="Socket Client (CustomStream, client side >classes)" depends="generate"> > >>> >classname="org.apache.commons.a

Re: [Altrmi] PATCH Passing pf remote obj ' ref

t 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... >> >>Regar

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 getM

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.apa

Re: [ALTRMI]-PATCH JNDI interface for Altrmi clients

Vinay, >>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 ? >> > >Hey Paul, I left some println' hanging in there >amongst the jndi code . >Can you get rid of t

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 do

Re: [ALTRMI]-PATCH JNDI interface for Altrmi clients

Vinay, >Paul, >Did some prelim' JNDI bridge work for client-side >lookup's and listing. > > > > >Comments ?? > I am over the moon I will put it in now! - Paul -- To unsubscribe, e-mail: For additional commands, e-mail:

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 >

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

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

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 ... > W

Re: [GUMP] Build Failure - altrmi

Folks, > >[javac] import org.beepcore.beep.core.BEEPError; > I need to create a beepcore.xml file in alexandia/proposal/gump/project/ like so: http://sourceforge.net/project/showfiles.php?group_id=24004&release_id=34510/"/> BEEP implementation for Java The jar is cont

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:

Re: [AltRMI] (PATCH) BEEP wire

Vinay, >Hi Paul, >We need a xml parser too along with beep libraries, >since BEEP exchanges xml messages > between peers to manage the channels/sessions >between the peers . >So maybe we can put xerces in /lib folder too.. > I did not know it depended on XML parsing. It's only a multiplexer o

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.* >

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 interfac

[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

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 cl

[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: For additional commands, e-mail:

Re: [AltRMI] multiplexing over single connection

ross 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 &g

[AltRMI] multiplexing over single connection

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

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 nec

Re: [AltRMI] Passing stubs around

Vinay, >Paul, > >>This submitted too. Thanks. >> >welcome.. >So what would be the right way to >make the Provider-Consumer example run? > Sorry dude, I turned the bat files into ant targets : ant -buildfile tests2.xml procon-serve ant -buildfile tests2.xml procon-client - Paul -- To u

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 -- T

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: For additional commands, e-mail:

[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 th

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 examp

Re: AltRMI chat (was: [OT] J2EE considered harmful)

Paulo, >Moving this to the Commons. Please reply only in the commons-dev list. > >Sorry Paul, I meant AspectJ. > >I do not understand the incompatibility between Dynamic proxies and >BeanShell. What is it. > Well unless the interface it is implementing is also in beanshells classpath, bean

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, Invers

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

Re: Commit Status Request

Jeff, >This is Jeff Prickett and I would like to request Commit Status in the >Commons so that I can continue iCalendar development and attempt to >build a community around the product. > +1 from me. I'm not quite sure of the voting rules given that I am active in one Commons project only. I s

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: For additional commands, e-mail:

Re: [PATH] Altrmi support for build.sysclasspath

Thanks Sam, Will apply. - Paul >[[ resubmitting with a better subject line ]] > >Patch to allow AltrmiInterfaceTask to support build.sysclasspath (see >http://jakarta.apache.org/ant/manual/sysclasspath.html for details). For >now, I coded the default to be to "ignore" the CLASSPATH environment

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

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 >

Re: [AltRMI] New Direct-Marshalled transport type

Juozas, > > >>> 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. >

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-St

[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. -

Jasper's java compiler.

In Tomcat-jasper project there is a note about the 'javacompiler' package : " Generic component, not specific to jasper ( could be moved to commons ). " Is there much interest in a Java compiler in commons? If yes, we should liase with the Tomcat/Jasper teams. Regards, - Paul H -- To un

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?

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 to

AltRMI - a task for a newbie.

Folks, I've written a HostContext that can delegate to one of many other host contexts. The impl so far just rotates round its list for load balancing. There is plenty of opportunity for others as previously mentioned (random, profiling types ,etc). Just clone a class, code, test and submi

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 s

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 g

Re: AltRMI - Proposal & request for help

James, Folks, >> 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 p

Re: AltRMI & load balanced requets from client to server(s)

Incze, >Oe Mon, Jan 21, 2002 at 09:57:47AM +0000, 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

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:

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 no

Re: AltRMI Tasks if anyone want to take them

James, >>1) JNDI bindings. Avalon-Excalibur has a generic provider for RMI. It >>should be fairly easy to copy for AltRMI. If keen, I can pass on URLs to >>the CVS files. >> > >Just a thought - there's a bunch of JNDI code, utilities and providers all >over the place in different projects. Mayb

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 se

Re: AltRMI & load balanced requets from client to server(s)

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

Re: AltRMI performance figures

Juozas, > I don't succseed to run all ARMI tests, don't understand me wrong, I > do not blame your, it is very usual, > It seems my problem not ARMI, it hangs on test1a-serve and I have IO > and connection Exceptions, Did you also launch the "test1a-client" in a second shell ? The IOException

AltRMI Tasks if anyone want to take them

Folks, 1) JNDI bindings. Avalon-Excalibur has a generic provider for RMI. It should be fairly easy to copy for AltRMI. If keen, I can pass on URLs to the CVS files. 2) True dynamic proxy generation. At the moment the proxies are created via Ant tasks, Using either BCEL or JCFE it will be p

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 me

Re: AltRMI - Proposal & request for help

James, >Sorry this mail is really late - I've been offline. I just wanted to day >that AltRMI sounds very interesting, I'm keen to help out - particularly >adding JMS bindings, that sounds right up my street. > Welcome aboard then :-) The first thing to do is get it from CVS, compile and run it

[AltRMI] More use of

ethod 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

Re: AltRMI - Proposal & request for help

of technique (a >dynamic proxy) in a current application to insulate the client from >RemoteExceptions, log all call entries/exits, etc. > >I'm not trying to "dis" AltRMI at all, just pointing out the availability of >other solutions if those are your primary objections to RMI. >

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 c

AltRMI - Proposal & request for help

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 conver

Re: [GUMP] Build Failure - altrmi

Ted, > >/home/rubys/jakarta/jakarta-commons-sandbox/altrmi/build.xml:186: Manifest file: >/home/rubys/jakarta/jakarta-commons-sandbox/altrmi/src/conf/MANIFEST.MF does not >exist. > Fixed. To illustarte how a rusty mind works, it is the second time I made the same mistake. It was left out or

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

Re: [Vote] ARMI as Commons package +1

Ted, >I believe that its possible that not enough of us understand the >background of the ARMI codebase. > >There's a lot going on, and it can be helpful to spoonfeed us old, >feeble, and bandwith-challenged folk =:0) > Primarily it is an alterative to RMI. It exports* method calls to other pr

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: For additional commands, e-mail:

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: For additional commands, e-mail:

Re: [Vote] ARMI to move

Scott, >Why not just altrmi? > Yes, thats good enough. , how about a vote on the migration? - Paul -- To unsubscribe, e-mail: For additional commands, e-mail:

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 i

Re: [Vote] ARMI to move

Scott, >Isn't it some form of RPC? A lightweight form at that? > Yup. - Paul -- To unsubscribe, e-mail: For additional commands, e-mail:

[Vote] ARMI to move

Folks, http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/armi/ I have done a lot of work on ARMI and think it is time for me to ask committers to vote for a move of this tool from 'sandbox' in to the main CVS tree. It also needs a rename (ARMI is already used in the context of Java by

Re: ARMI mobilisation?

Juozas, > > > 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 f

Re: [ARMI] authentification

Gerhard, >Hi Paul, all, >just subscribed. Jakarta is going to be a >obsession for me. > >(Maybe some people know me from other lists: >#1 I'm the only lurker with commit rights >in the Avalon Project ;) > You're wrong there, most are here as Lurkers and Jeff will be a committer before long :-)

Re: [ARMI] Fail to make jar.

Eung-ju, >src/conf/MANIFEST.MF is missed. > Fixed. Sorry! - Paul -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: ARMI mobilisation?

Lance, >>Any thoughts for ARMI (though it needs a rename as "Async RMI" >>used). Is commons the place for it? Yes/No? >> > >Paul, > >Sorry I haven't had an opportunity to test ARMI yet, but thought I'd >chime in here anyway: >I always thought (somehow) that ARMI stood for "Alternative RMI" ;-) >

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: For additional commands, e-mail:

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 get

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

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 - t

Re: New tool - armi - 'alternate to RMI'

Scott, Craig, James, Juozas, Chris, Lance, It is booked in. CVS ain't so difficult when used via IDEA/2. I still prefer Perforce and look forward to a finished Subversion. build.xml - default target is "compile" test.xml - default target is "generate" The two are separate as the forst generat

Re: New tool - armi - 'alternate to RMI'

Scott, >You have the karma to start it in the sandbox. > :-) >I can help with the layout if you want me to. > Nahh tis done (you mean directory/package hierarchy?). I copied from beanutils. *Speed results* Test#1 Test#2 Direct 30 30 (one VM, main thread) Pipe

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 t

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/ Commo

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 fr

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 fu

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

  1   2   >