Hi, > Optimization is one aspect - but keep in mind that your exposing
putting aside the concern about misuse of my component (internal apps mainly).... Is using a non-proxied component to make service method calls order of magnitude faster or slightly faster or is it pretty much given that if you want faster calls on your service methods, you should use non-proxied components as first choice? I guess one way to ask this is: if you guys(avalon developers) out there working for a client who has a requirement to have a "very fast service" implementation, would make "non proxiing" your service component as one of your first choices to optimize your service. regards Korosh. > lifecycle interfaces which means that consumers (which you have no > control over) can potentially do things to your component. However - > you can code against this but ensuring that your lifecycle operations > are only invoked once and throwing an illegal state exception otherwise > - etc. Other example of the need for non-proxied component exposure > include things like org.omg.corba.ORB which is itself a class that is > acting as a big proxy to an underlying implementation. > > All you need to worry about is a little defensive programming on the > lifecycle stage operations - but aside from that - no problem. > > Stephen. > > > > > Korosh. > > > > > > > > > > On Sat, 2004-01-31 at 01:12, Stephen McConnell wrote: > > > >>john lukar wrote: > >> > >> > >>>I can be making 100's of > >>>such method calls on my service per second and speed > >>>is important. > >> > >>What you can do is disable proxy generation for a particular component. > >> This is needed sometimes for objects that are themselves acting as > >>proxies. The solution is to include the attribute key > >>"urn:activation:proxy" with a value of "false" in the xinfo <type> > >><info> <attributes> element. > >> > >>For example: > >> > >><type> > >> <info> > >> <name>simple</name> > >> <lifestyle>singleton</lifestyle> > >> <attributes> > >> <attribute key="urn:activation:proxy" value="false"/> > >> </attributes> > >> </info> > >> : > >></type> > >> > >>This is not tied into the meta-info generation at this time (we still > >>need to add generic attribute handling) - so you going to have to > >>maintain the xinfo file manually and make sure it is included into the > >>target/classes directory after the avalon:meta and before the jar:jar > >>goal. BTW - there is an example of this in one of the test cases in the > >>activation impl package. Just search for "urn:activation:proxy". > >> > >>Steve. > >> > >> > >>>thanks for information on this. > >>> > >>>John. > >>> > >>>__________________________________ > >>>Do you Yahoo!? > >>>Yahoo! SiteBuilder - Free web site building tool. Try it! > >>>http://webhosting.yahoo.com/ps/sb/ > >>> > >>>--------------------------------------------------------------------- > >>>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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
