Re: private vs. protected access
Vincenzo Gianferrari Pini wrote: +1 > Mainly for the supplied matchers and mailets, adding protected getter/setter methods. +1 This is a very sound and clean initiative. We should perhaps also write a "mailet/matcher coding best practices" wiki page. +1 "Also, while making this change it might be worth considering adding a prefix to the variable names, 'field' is typical. So... ... This has two advantages. Firstly, it avoids mistaken direct access to the variable and secondly it makes the class JavaBean compatible..." +1 for the first reason, but I think that it is JavaBean compatible even without the renaming. +0. I've seen this.name = name cause problems, so whatever workaround makes the coder doing it happy. Dunno if it's worth refactoring existing stuff. -- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
+1 Mainly for the supplied matchers and mailets, adding protected getter/setter methods. This is a very sound and clean initiative. We should perhaps also write a "mailet/matcher coding best practices" wiki page. "Also, while making this change it might be worth considering adding a prefix to the variable names, 'field' is typical. So... ... This has two advantages. Firstly, it avoids mistaken direct access to the variable and secondly it makes the class JavaBean compatible..." +1 for the first reason, but I think that it is JavaBean compatible even without the renaming. Vincenzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] RemoteDelivery multiple delay times
- Original Message -
From: "Andreas Göggerle" <[EMAIL PROTECTED]>
To: "'James Developers List'" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, October 30, 2003 3:30 PM
Subject: RE: [PATCH] RemoteDelivery multiple delay times
> But i still have one (minor?) problem with my Mailet to be RFC conform:
> JavaMail 1.3.1 doesn't support the MIME-Type "message/delivery-status" and
I
> don't have the time to look at the JavaBeans Activation Framework for
> writing an own DataContentHandler for this MIME-Type. At the monent I send
> the delivery-report as MIME-Type "text/plain". If someone is willing to do
> the DataContentHandler or if you want to accept it even if it's not 100%
RFC
> conform I can contribute the current Mailet.
>
> Andreas
Servus Andreas,
you dont need to write your own DataHandler, just use what allready exists.
You could use the default Handler of the message/rfc822-messages and extend
the MimeMessage class.
For example your mailcap-file (take a look at mail.jar/META-INF/mailcap)
would then look something like this:
"...
message/rfc822;; x-java-content-handler=com.sun.mail.handlers.message_rfc822
message/delivery-status;;
x-java-content-handler=com.sun.mail.handlers.message_rfc822"
and your own MimeMessage class maybe like this:
"...
public class DSNMessage extends MimeMessage {
private String type = "";
public DSNMessage() {
super(Session.getDefaultInstance(System.getProperties(), null));
}
public void setContent(Object o, String type) throws MessagingException {
this.type = type;
super.content = (byte[])o;
}
public void writeContentTo(OutputStream outs)
throws java.io.IOException, MessagingException {
outs.write(super.content);
outs.flush();
}
public void writeTo(OutputStream outs, String as[])
throws IOException, MessagingException
{
outs.write(super.content);
outs.flush();
}
}".
If you want to test it, here is a suggestion:
"...
private void test() {
try {
MimeMultipart mp = new MimeMultipart();
MimeBodyPart body1 = new MimeBodyPart();
body1.setContent("Plain TEXT","text/plain");
mp.addBodyPart(body1);
Session session = Session.getDefaultInstance(System.getProperties());
MimeBodyPart body2 = new MimeBodyPart();
Message m = new DSNMessage();
m.setContent(new
String("DSN-MESSAGE").getBytes(),"message/delivery-status");
body2.setContent(m,"message/delivery-status");
mp.addBodyPart(body2);
// Andreas if you want to support type text/rfc822-headers you would
definetly repeat the steps above
MimeBodyPart body3 = new MimeBodyPart();
body3.setContent("RFC822-HEADER","text/rfc822-headers");
mp.addBodyPart(body3);
Message msg = new MimeMessage(session);
ContentType cType = new ContentType();
cType.setPrimaryType("multipart");
cType.setSubType("report");
cType.setParameter("report-type", "delivery-status");
String contentType = cType.toString();
msg.setContent(mp,contentType);
msg.saveChanges();
msg.writeTo(System.out);
}
"
Hope this helps.
M
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Merging plan (was Build process in maven?)
> We're already close. The linkages between SMTP, NNTP, POP3, > IMAP and the pipeline are all through the spooler or the > repositories. I've been toying with the idea of a > distributed spooler for most of the year. The problem is > that we have to synchronize access to items (only one > processor should take an item for processing), and we need to > recover if a processor fails to complete processing of an item. > > These issues are why I've started to think that instead of a > distributed spool mechanism, we should consider a central > spooler with clustered processors. It would be easier to > control and recover, since the spooler would control access, > and would know if a processor failed. This is why I think JMS is actually a good fit for the spooler queuing mechanism. A JMS queue can have multiple readers and JMS guarantees that the each message will be delivered to one reader one time only. The reader can use manual acknowledgement of messages once it has completed processing it or secured it locally. Messages that are not acknowldeged will be delivered to another reader after a suitable timeout. Since JMS provides so much of what is needed, I think it would be a great starting point and since the spooler implementation is a configurable component it would be easy to replace later or even provide alternate implementatations for different needs. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status of JMS
> From: Danny Angus wrote: > Anyway lets carry on turning over rocks and see what crawls out Once we start distributing function across JVMs we have to be real smart to avoid a performance impact regardless of the protocol used. We also have to take care that the changes do not adversely impact non-distributed deployments.[1] Distribution invariably incurs the cost of serializing/deserializing to/from the transport. The trick is to transport the minimum necessary. In my experience, though the performance of particular implementations of JMS varies enormously, the dominant variant is the size of the objects transported. Another thing to remember is that JMS is just an interface specification. You can plug-in different implementations, but don't expect those implementations to talk to one and other without a JMS<>JMS bridge. That said, if we decide that distributed asynchronous processing is the way to go, I can see no rationale for cooking our own interface and implementation. I work in environments that support JMS transaction rates way above those typical of James, albeit with bigger hardware budgets. JMS also offers the opportunity of load-balancing by having several message consumers, offering the potential to increase the scalability of James. To me this is highly attractive. As Danny says, just "turning over rocks". -- Steve [1] In house we use a null JMS implementation wherein nothing ever gets serialized for local deployments. - - - - - - - - - - - - - - - - - - This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
We have to support what we release as a public interface. In some cases, the code as it exists may not be what we want to support, and that is another reason for why it isn't exposed. In the specific case of the RemoteDelivery mailet, rather than having to track changes, if/when he submits his change, it could be incorporated into the next build. I am not saying that we should not expose some things that aren't, but let's be judicious about it. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Status of JMS
I believe OpenJMS is compatible in binary form, but source suffers from the Intalio indemnity problem. JORAM was (is?) LGPL, but ObjectWeb have started to switch their projects to an ASF-friendly license (ASM just switched to BSD for example). -- Jeremy > -Original Message- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 04, 2003 7:07 PM > To: James Developers List; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: Status of JMS > > > Jeremy Boynes wrote: > > James Strachan wrote: > > > I'd use OpenJMS or JGroups for now. There is no JMS implementation > > > inside Geronimo yet & I can't imagine there would be one for a while. > > > The intention is to integrate an existing JMS implementation > using JCA now > > that we have transaction and security inflow. I believe OpenJMS > is working > > on that; JORAM would be another possibility. > > Are the licenses for both of those compatible? > > --- Noel > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
Søren Hilmer wrote:
>
>
> No, I believe we are exactly on the same wavelength, I would
> not really make
> the instance variables protected, just supply
> getters/setters, which amounts
> to the same functional wise, I guess I was not clear on that.
Excellent!
If you happen to use Eclipse, its refactoring tool includes self
encapsulation. This may save some time.
Also, while making this change it might be worth considering adding a prefix
to the variable names, 'field' is typical. So...
private String name;
protected String getName()
{
return this.name;
}
protected void setName(String name)
{
this.name = name;
}
becomes...
private String fieldName;
protected String getName()
{
return name;
}
protected void setName(String name)
{
fieldName = name;
}
This has two advantages. Firstly, it avoids mistaken direct access to the
variable and secondly it makes the class JavaBean compatible. Again, Eclipse
helps out with the rename refactoring tool.
Not a big deal, but if we are tidying up variable access we may as well do
everything that needs to be done in one pass.
-- Steve
- - - - - - - - - - - - - - - - - -
This private and confidential e-mail has been sent to you by Synergy Systems Limited.
It may not represent the views of Synergy Systems Limited.
If you are not the intended recipient of this e-mail and have received it in error,
please notify the sender by replying with "received in error" as the subject and then
delete it from your mailbox.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: private vs. protected access
No, I believe we are exactly on the same wavelength, I would not really make the instance variables protected, just supply getters/setters, which amounts to the same functional wise, I guess I was not clear on that. --Søren On Wednesday 05 November 2003 11:05, you wrote: >Søren Hilmer wrote: >> >> I propose the following change(s). >> >> Mainly for the supplied matchers and mailets I would like to >> reconsider having >> instance variables and methods being of private access and >> move promote them >> to protected access. > >Lets look at the intent of this change which is (please correct me if I am >wrong) to facilitate specialization by subclassing. This requires that >classes follow a few simple rules: > >1) Only expose as public methods that must be accessible to external classes >and are guaranteed to be maintained throughout the class' development >lifecycle. Such methods should ideally be defined in an interface. > >2) Only make private methods which should never be exposed to subclasses, >such as required constructors which only partially establish an instance's >state, basic getters for lazily initialized variables, etc. > >3) The remaining methods should be made protected. > >4) Public and protected methods should be sufficiently granular to enable >specialization of a sole behavior. The specializing method should not need >to duplicate code in the superclass method. (If it does, refactor!) > >5) All variables should be private and self-encapsulating, ie: access both >within and without the class should be via getter and setter methods. > >Of the above, I would have thought only (5) is particularly contentious. >Martin Fowler covers this in "Refactoring : improving the design of existing >code", p171. > >Like Martin, I am willing to live with direct access within the defining >class. > >Direct access from outside of the defining class should never be permitted >as it breaks encapsulation and increases coupling. The specializing class >should not need to know how a value is maintained and should simply invoke >the getter/setter methods. These methods may access a variable directly, >perform lazy initialization or delegate off to another class. The >specializing class should neither know or care. > >So Søren, I am basically with you on making most methods protected but very >much against making variables protected. Rather, we should make them private >and add getter/setter methods! > >-- Steve > -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
Steve Brewin wrote: > and add getter/setter methods! should read... and add protected getter/setter methods! -- Steve - - - - - - - - - - - - - - - - - - This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: private vs. protected access
Søren Hilmer wrote: > > I propose the following change(s). > > Mainly for the supplied matchers and mailets I would like to > reconsider having > instance variables and methods being of private access and > move promote them > to protected access. Lets look at the intent of this change which is (please correct me if I am wrong) to facilitate specialization by subclassing. This requires that classes follow a few simple rules: 1) Only expose as public methods that must be accessible to external classes and are guaranteed to be maintained throughout the class' development lifecycle. Such methods should ideally be defined in an interface. 2) Only make private methods which should never be exposed to subclasses, such as required constructors which only partially establish an instance's state, basic getters for lazily initialized variables, etc. 3) The remaining methods should be made protected. 4) Public and protected methods should be sufficiently granular to enable specialization of a sole behavior. The specializing method should not need to duplicate code in the superclass method. (If it does, refactor!) 5) All variables should be private and self-encapsulating, ie: access both within and without the class should be via getter and setter methods. Of the above, I would have thought only (5) is particularly contentious. Martin Fowler covers this in "Refactoring : improving the design of existing code", p171. Like Martin, I am willing to live with direct access within the defining class. Direct access from outside of the defining class should never be permitted as it breaks encapsulation and increases coupling. The specializing class should not need to know how a value is maintained and should simply invoke the getter/setter methods. These methods may access a variable directly, perform lazy initialization or delegate off to another class. The specializing class should neither know or care. So Søren, I am basically with you on making most methods protected but very much against making variables protected. Rather, we should make them private and add getter/setter methods! -- Steve - - - - - - - - - - - - - - - - - - This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: private vs. protected access
+1 to Soren's proposal, as long as it is done intelligently :-) > I propose the following change(s). > Mainly for the supplied matchers and mailets ... > instance variables and methods ... > promote them to protected access. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
private vs. protected access
Hi, I propose the following change(s). Mainly for the supplied matchers and mailets I would like to reconsider having instance variables and methods being of private access and move promote them to protected access. Lets take Andreas' DSNBounce as an example of what I am suggesting. Now to make this Andreas had to make a change to RemoteDelivery failMessage, but failMessage has private access, so Andreas have had to make his own copy of RemoteDelivery to make this change, now when RemoteDelivery for some reason changes in James, he will have to get this new version and patch in his changes (major inconvenience). Now had failMessage had protected access, he could just have inherited from RemoteDelivery and overridden failMesssage, voila. The same goes for a lot of the instance variables, when they are private you cannot get to them in subclasses (and usually there are no protected set/get access methods as well) and it evidently leads to copy paste coding, which I consider bad. As the situation is now, a lot of the mailets/matchers could just as well have been declared final. I won't mind doing the grunt work on this one. --Søren -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ Fax:+45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
