1. Even though I am not completing the total TurbineXXX.uglyStaticMethod() removal, it does not mean you can't use it in the new avalonized code base. I personally won't be doing it, but it can be done. I have kept it in the fulcrum code for migration purposes.
2. Also, JASF is not really in use anywhere yet, but has been a thought experiment. I would like to use it but am still a bit unsure about it and the way it is designed. So, please give your feedback/questions.
3. I think it would be nice if a new torque security service was written in conjunction with JASF in mind if it stands up to people's criticisms. (in fact I have it on my list to write one, but it is way down there ATM). There is already a little xml implementation.
4. I will be working with JASF a little this week as I try to use it's XML to webpage mapping capability to get rid of my 50 screen classes in an old app of mine that I'm porting to summit. I suppose this will be the real usability test :)
Anything more I can expand on?
- Dan Diephouse
Scott Eade wrote:
From the discussions so far it seems that the Security Service is pretty much the only one that will not (read this as cannot) be ported forward to be an avalon component without a total rewrite (thus making it forward compatible with summit/plexus).It will be interesting to see what is proposed for summit/plexus as some kind of security service is IMO a must have requirement. I guess Dan's JASF code might be developed further for this purpose - do you have any insight into this Dan? Having looked over the security code briefly in the last week, I don't think it would be too difficult to provide a further implementation of the existing security service that does not use torque - not too easy, but not too difficult (the LDAP support was only recently made to work). HTH, Scott
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
