Performance wise, it seems like JUEL beats OGNL on nested expressions, but it is a little bit slower at arithmetic, meh. The UEL plugin is working better than I expected, so I will try to get it out of the sandbox for the next release (whenever that is).
musachy On Sat, Nov 21, 2009 at 4:53 PM, Chris Pratt <thechrispr...@gmail.com> wrote: > Unfortunately the same cannot be said for OGNL. I spent most of Friday > going through the interwebs archives and finding out that one major sticking > point in my architecture (and all of yours) is that OGNL synchronizes just > about everything. I spent about 6 hours going through the code and removing > some of the offending blocks. I'm hoping that Musachy's latest attempt at > removing OGNL all together will end up being the ultimate solution, but only > time will tell. > (*Chris*) > > On Sat, Nov 21, 2009 at 4:48 PM, Martin Gainty <mgai...@hotmail.com> wrote: > >> >> so >> shared variable-use synchronized >> not-shared variable-use threadLocal >> >> struts code has only a few synchronized blocks or synchronized methods >> but plenty of ThreadLocal<Object> specifically the all important Dispatcher >> instance >> private static ThreadLocal<Dispatcher> instance = new >> ThreadLocal<Dispatcher>(); >> >> thanks chris >> Martin Gainty >> ______________________________________________ >> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité >> >> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene >> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte >> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht >> dient lediglich dem Austausch von Informationen und entfaltet keine >> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von >> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. >> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le >> destinataire prévu, nous te demandons avec bonté que pour satisfaire >> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie >> de ceci est interdite. Ce message sert à l'information seulement et n'aura >> pas n'importe quel effet légalement obligatoire. Étant donné que les email >> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter >> aucune responsabilité pour le contenu fourni. >> >> >> >> >> > To: user@struts.apache.org >> > Subject: Re: (clearly O/T) use of ThreadLocal vs Synchronized >> > Date: Sat, 21 Nov 2009 19:27:16 -0500 >> > From: musom...@aol.com >> > >> > >> > They are quite distinct -- ThreadLocal variables are not shared at all >> while synchronized permits sharing (but not concurrently). >> > Suppose you have a background thread that does some calculation that you >> might need [in my case you have an abstract >> > graph and a background thread is checking if the graph has intersecting >> edges so that algorithms that need to know can >> > use a cached answer rather than calculate it at the time they need it]. >> You can't use a thread local because you want the >> > background thread to play with the very same variable but still not get >> in the way of the main thread of the algorithm. >> > >> > >> > >> > Chris >> > >> > >> > >> > >> > -----Original Message----- >> > From: Martin Gainty <mgai...@hotmail.com> >> > To: Struts Users Mailing List <user@struts.apache.org> >> > Sent: Sat, Nov 21, 2009 8:38 am >> > Subject: (clearly O/T) use of ThreadLocal vs Synchronized >> > >> > >> > >> > Good Morning All- >> > >> > are there any instances where a factory use of synchronized keyword is >> preferred >> > or considered more efficient implementation over creating a ThreadLocal >> object? >> > >> http://www.javamex.com/tutorials/synchronization_concurrency_thread_local2.shtml >> > >> > any answers are appreciated! >> > Martin Gainty >> > ______________________________________________ >> > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité >> > >> > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene >> Empfaenger >> > sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte >> Weiterleitung >> > oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient >> lediglich dem >> > Austausch von Informationen und entfaltet keine rechtliche >> Bindungswirkung. >> > Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine >> Haftung >> > fuer den Inhalt uebernehmen. >> > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas >> le >> > destinataire prévu, nous te demandons avec bonté que pour satisfaire >> informez >> > l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de >> ceci est >> > interdite. Ce message sert à l'information seulement et n'aura pas >> n'importe >> > quel effet légalement obligatoire. Étant donné que les email peuvent >> facilement >> > être sujets à la manipulation, nous ne pouvons accepter aucune >> responsabilité >> > pour le contenu fourni. >> > >> > >> > >> > _________________________________________________________________ >> > Bing brings you maps, menus, and reviews organized in one place. >> > >> http://www.bing.com/search?q=restaurants&form=MFESRP&publ=WLHMTAG&crea=TEXT_MFESRP_Local_MapsMenu_Resturants_1x1= >> > >> > >> >> _________________________________________________________________ >> Bing brings you maps, menus, and reviews organized in one place. >> >> http://www.bing.com/search?q=restaurants&form=MFESRP&publ=WLHMTAG&crea=TEXT_MFESRP_Local_MapsMenu_Resturants_1x1 >> > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
