[Rife-users] Ready to use elements for user and task creation
Hi, I know that there are some ready to use elements for logout, printing etc. Are there any others whick can be used to create/update/delete tasks and create/update/delete site users ? ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] Classloader error
not that i'm experiencing this, but yes, pls post the specifics. thanks, eokyere On 4/12/06, Eddy Young [EMAIL PROTECTED] wrote: Eddy Young wrote: Hi all, Is there a known classloader-related error between RIFE and Log4J? Indeed, there was a classloader-related problem between RIFE and Log4j, as Geert managed to track down. But, it is debatable whether the fault can be attributed to RIFE at all. If you want to know the specifics, please ask. We can then post a detailed analysis which might even be useful to troubleshoot similar problems in your applications. In short, the solution is to move Log4J jar-files from WEB-INF/lib into common/lib of the servlet container *and* restart the container. Eddy -- http://coding.mu http://priscimon.com/blog ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users -- Johann Wolfgang von Goethe - Character develops itself in the stream of life. ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] Ready to use elements for user and task creation
Hi Gokhan, there are only a bare minor amount of functional elements that ship with RIFE's core distribution. You can however reuse any of the elements that are present in RIFE/ Crud, Bamboo, Elephant, Bla-bla List, Javapaste, ... Also, I'm hoping that one day people will start working on some add- on jars that will contain general purpose elements that are neatly designed and packaged for reuse. If you end up writing these yourself, consider contributing them back, I'll gladly setup the required infrastructure for you within the project (SVN, Issue tracker, wiki, ...). Best regards, Geert On 01 May 2006, at 01:43, GOKHAN YAMAC wrote: Hi, I know that there are some ready to use elements for logout, printing etc. Are there any others whick can be used to create/update/delete tasks and create/update/delete site users ? ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users -- Geert Bevin Uwyn bvba GTalk: [EMAIL PROTECTED] Use what you need Avenue de Scailmont 34 Skype: gbevin http://www.uwyn.com 7170 Manage, Belgium AIM: geertbevin gbevin at uwyn dot com Tel: +32 64 84 80 03 Mobile: +32 477 302 599 PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9 Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] Classloader error
Hi Emmanuel, here's a brief overview of what is happening. RIFE does one 'nasty' trick in its classloader that doesn't respect the standard contract for classloaders. Normally, a classloader is supposed to first delegate the loading of classes to the parent classloader (which is this case is the web application's servlet classloader). However, if RIFE does this, it would not be able to load any of the web application's classes, since the parent classloader is able to load them all. So what RIFE does is artificially trying to determine which classes and jars are part of the web application alone. It does this by looking up their resources and checking for the presence of WEB- INF. Sadly I wasn't able to find a standard way that allows you to do this, but this seems to work fine. At that point, all the web app classes can be automatically instrumented at load time for continuations and meta data merging. This problem arises when you have classes in your web applications that are loaded by other frameworks or libraries (Log4J for example) outside the scope of RIFE's filter or servlet. If these are accessed form within the RIFE application, RIFE has to check if the parent classloader hasn't already loaded them, since loading them twice would result into errors. This method works fine unless you have package-private classes that are not loaded outside the RIFE filter, but that are accessed by classes that are already loaded from within the RIFE filter. These package-private classes will not be loaded by the parent classloader, but they will be loaded by RIFE's instead, creating permission exceptions. I've tried to find ways around this while still maintaining the ease- of-use of RIFE's setup, but there's no strategy that I can come up with that allows solving this problem without extensive (and expensive) tracking of where the loaded classes belong. This would have a profound impact on performance. So the best solution is to move these libraries outside of WEB-INF, into the standard library of the servlet container. As far as RIFE is concerned, these are then outside the web application and will not be loaded by the RIFE classloader. The best solution now, is to wait a while for Mustang to come out and in the meantime develop a collection of instrumentation agents and get rid of the classloader. These agents need to be setup manually in 1.5, but in 1.6 there's a mechanism for them to be automatically and dynamically added at runtime. The agent does exactly what the classloader does, change the bytecode for additional functionalities. However, this will not fully replace RIFE's classloader, since there are some tricks in there for reloading element implementations, even if hotswap can'. Hope this was somewhat clear. Best regards, Geert On 01 May 2006, at 03:03, Emmanuel Okyere wrote: not that i'm experiencing this, but yes, pls post the specifics. thanks, eokyere On 4/12/06, Eddy Young [EMAIL PROTECTED] wrote: Eddy Young wrote: Hi all, Is there a known classloader-related error between RIFE and Log4J? Indeed, there was a classloader-related problem between RIFE and Log4j, as Geert managed to track down. But, it is debatable whether the fault can be attributed to RIFE at all. If you want to know the specifics, please ask. We can then post a detailed analysis which might even be useful to troubleshoot similar problems in your applications. In short, the solution is to move Log4J jar-files from WEB-INF/lib into common/lib of the servlet container *and* restart the container. Eddy -- http://coding.mu http://priscimon.com/blog ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users -- Johann Wolfgang von Goethe - Character develops itself in the stream of life. ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users -- Geert Bevin Uwyn bvba GTalk: [EMAIL PROTECTED] Use what you need Avenue de Scailmont 34 Skype: gbevin http://www.uwyn.com 7170 Manage, Belgium AIM: geertbevin gbevin at uwyn dot com Tel: +32 64 84 80 03 Mobile: +32 477 302 599 PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9 Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
Re: [Rife-users] Classloader error
Hope this was somewhat clear. it was, and educative too. thanks, Emmanuel On 5/1/06, Geert Bevin [EMAIL PROTECTED] wrote: Hi Emmanuel, here's a brief overview of what is happening. RIFE does one 'nasty' trick in its classloader that doesn't respect the standard contract for classloaders. Normally, a classloader is supposed to first delegate the loading of classes to the parent classloader (which is this case is the web application's servlet classloader). However, if RIFE does this, it would not be able to load any of the web application's classes, since the parent classloader is able to load them all. So what RIFE does is artificially trying to determine which classes and jars are part of the web application alone. It does this by looking up their resources and checking for the presence of WEB- INF. Sadly I wasn't able to find a standard way that allows you to do this, but this seems to work fine. At that point, all the web app classes can be automatically instrumented at load time for continuations and meta data merging. This problem arises when you have classes in your web applications that are loaded by other frameworks or libraries (Log4J for example) outside the scope of RIFE's filter or servlet. If these are accessed form within the RIFE application, RIFE has to check if the parent classloader hasn't already loaded them, since loading them twice would result into errors. This method works fine unless you have package-private classes that are not loaded outside the RIFE filter, but that are accessed by classes that are already loaded from within the RIFE filter. These package-private classes will not be loaded by the parent classloader, but they will be loaded by RIFE's instead, creating permission exceptions. I've tried to find ways around this while still maintaining the ease- of-use of RIFE's setup, but there's no strategy that I can come up with that allows solving this problem without extensive (and expensive) tracking of where the loaded classes belong. This would have a profound impact on performance. So the best solution is to move these libraries outside of WEB-INF, into the standard library of the servlet container. As far as RIFE is concerned, these are then outside the web application and will not be loaded by the RIFE classloader. The best solution now, is to wait a while for Mustang to come out and in the meantime develop a collection of instrumentation agents and get rid of the classloader. These agents need to be setup manually in 1.5, but in 1.6 there's a mechanism for them to be automatically and dynamically added at runtime. The agent does exactly what the classloader does, change the bytecode for additional functionalities. However, this will not fully replace RIFE's classloader, since there are some tricks in there for reloading element implementations, even if hotswap can'. Hope this was somewhat clear. Best regards, Geert On 01 May 2006, at 03:03, Emmanuel Okyere wrote: not that i'm experiencing this, but yes, pls post the specifics. thanks, eokyere On 4/12/06, Eddy Young [EMAIL PROTECTED] wrote: Eddy Young wrote: Hi all, Is there a known classloader-related error between RIFE and Log4J? Indeed, there was a classloader-related problem between RIFE and Log4j, as Geert managed to track down. But, it is debatable whether the fault can be attributed to RIFE at all. If you want to know the specifics, please ask. We can then post a detailed analysis which might even be useful to troubleshoot similar problems in your applications. In short, the solution is to move Log4J jar-files from WEB-INF/lib into common/lib of the servlet container *and* restart the container. Eddy -- http://coding.mu http://priscimon.com/blog ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users -- Johann Wolfgang von Goethe - Character develops itself in the stream of life. ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users -- Geert Bevin Uwyn bvba GTalk: [EMAIL PROTECTED] Use what you need Avenue de Scailmont 34 Skype: gbevin http://www.uwyn.com 7170 Manage, Belgium AIM: geertbevin gbevin at uwyn dot com Tel: +32 64 84 80 03 Mobile: +32 477 302 599 PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9 Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users -- Benjamin Disraeli - Nurture your minds with great thoughts. To believe in the heroic makes heroes. ___ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users
