Noel J. Bergman wrote: >Paul, > >Yes, TCP/IP is a factor, but I'd be more concerned about GC and memory >issues, not the CPU impact of performing the clone(). > I did not mention clone(), and I'll reassert that it is pointless to consider instantiation issues for a heavy TCP/IP using tool.
>However, it is a bit >of a moot point, since the mail object is largely a carrier for >javax.mail.internet.MimeMessage, which is not immutable (more on this in a >moment). > Perhaps you should consider a clean MimeMessage interface for your maillet API. >>There is _nothing_ wrong with having a small tree of interfaces for >>Maillet types. >> >> > >A "small tree of interfaces" wasn't the issue. The issue was the loss of >polymorphism. Although that isn't always a fatal flaw, the loss of >polymorphism is never a good thing, and should be avoided without very good >reason. That is just good general policy. In this case, I think that there >are other ways to achieve the desired goal(s). > >One simple solution would be something like: > > recipients = matcher.match(matcher.isAllowedChange() ? mail : >mail.duplicate()); > > mailet.service(mailet.isAllowedChange() ? mail : mail.duplicate()); > Yup that is good too. I'd vote for a single multi-purpose method as long as the container had pre-profiled the _XML_ declarations for the maillet. The downside is that it is a smell to return void when the maillet has no need for forwaring a mail back into the pipeline. >(nb: if we care about mail.getState(), we'll have to keep a reference long >enough to check it). That would create a copy for any matcher or mailet not >allowed to affect a change in the content of the object. > >The aforementioned approach says, "we don't know what you might do, and >can't keep track, so we'll simply give you a copy to damage as you might" >but it does not address the general problem of malicious components. For >example, a malicious mailet involved in industrial espionage could still >quietly queue up copies. > >This is a general problem, of which the same could be said of rogue Blocks, >servlets, or any other pluggable component in a pluggable architecture. > I disagree. The applet model has not been broken ( in terms of security ) in anything other than a denial of service attack (redirect, opening of windows). Blocks similarly are fine in terms of security, a malicious block cannot hack the kernel... > >The Java answer to this general problem appears to be Java Security. > Yes yes, which Phoenix (and other containers) leverage too. >A >wrapper on mutable components, e.g., MimeMessage, could do security checks >to see if there is permission to affect the desired change. Likewise, there >could be a permission check to see if a mailet is permitted to post a new >message to a processor queue. Now the administrator can control exactly >what operations are permitted by a given component. > Yup.... given their XML declarations.... in MAILLET-INF/maillet.xml - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
