I use EL to access nested object data far more often than I use it to perform arithmetic, that's what the action is for. (*Chris*)
On Sun, Nov 22, 2009 at 1:11 AM, Musachy Barroso <musa...@gmail.com> wrote: > 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 > >
