[jira] [Created] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
Mirko Raner created CODEC-158:
-
Summary: Add Codec, StringCodec, and BinaryCodec interfaces that
extend both encoder and decoder
Key: CODEC-158
URL: https://issues.apache.org/jira/browse/CODEC-158
Project: Commons Codec
Issue Type: Improvement
Affects Versions: 1.7
Reporter: Mirko Raner
Priority: Minor
Currently, there are no common interfaces that extend both the encoder and the
decoder interfaces. This makes it hard to deal with a codec as a single entity
and requires separate treatment of encoder and decoder parts.
For example, let's say you want to develop a storage abstraction that uses an
encoding. Right now, you would need to write
class Storage
{
@Inject Encoder encoder;
@Inject Decoder decoder;
//...
}
In practice, encoder and decoder need to match, and most likely both encoder
and decoder would be bound to the same implementation, like Base64 or URLCodec.
Because of the lack of a common superinterface they need to be specified
separately. There are some classes like BaseNCodec that can be used to unify
some of the encoders and decoders, but they are too specific and restrictive.
Ideally, I would like to write:
class Storage
{
@Inject Codec codec;
//...
}
Assuming that combined encoder/decoder classes like Base64 would implement that
Codec interface, this could be directly bound to a combined encoder/decoder
implementation.
It would be nice if these interfaces were added and the existing codec classes
(BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be modified to
implement these new interfaces.
I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (NET-481) Commons TFTP does not support RFCs 2347 and 2349
Mirko Raner created NET-481: --- Summary: Commons TFTP does not support RFCs 2347 and 2349 Key: NET-481 URL: https://issues.apache.org/jira/browse/NET-481 Project: Commons Net Issue Type: Improvement Components: TFTP Affects Versions: 3.1, 1.4 Reporter: Mirko Raner Priority: Minor Commons TFTP does not implement RFC 2347 (TFTP Option Extension) and RFC 2349 (TFTP Timeout Interval and Transfer Size Options). Implementing these two RFCs involves a new packet type (OACK) as well as additional optional header fields in existing read and write request packets. We recently had to do this work for an internal project and are considering to contribute our patches back to the project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirko Raner updated CODEC-158:
--
Attachment: CODEC-158.patch
Attached are the modifications I had in mind to address this. Please let me
know if you have any questions or improvements.
There is already a class called BinaryCodec in package
org.apache.commons.codec.binary. The new BinaryCodec interface in
org.apache.commons.codec may be confused with this existing class. In the
patch, the naming is consistent (i.e. StringEncoder+StringDecoder->StringCodec
and BinaryEncoder+BinaryDecoder->BinaryCodec) and the two types are
distinguishable by their package. If you feel this could be a problem, please
make a suggestion as to how this can be resolved.
Thanks!
> Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
> and decoder
> ---
>
> Key: CODEC-158
> URL: https://issues.apache.org/jira/browse/CODEC-158
> Project: Commons Codec
> Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Mirko Raner
>Priority: Minor
> Attachments: CODEC-158.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, there are no common interfaces that extend both the encoder and
> the decoder interfaces. This makes it hard to deal with a codec as a single
> entity and requires separate treatment of encoder and decoder parts.
> For example, let's say you want to develop a storage abstraction that uses an
> encoding. Right now, you would need to write
> class Storage
> {
> @Inject Encoder encoder;
> @Inject Decoder decoder;
> //...
> }
> In practice, encoder and decoder need to match, and most likely both encoder
> and decoder would be bound to the same implementation, like Base64 or
> URLCodec. Because of the lack of a common superinterface they need to be
> specified separately. There are some classes like BaseNCodec that can be used
> to unify some of the encoders and decoders, but they are too specific and
> restrictive.
> Ideally, I would like to write:
> class Storage
> {
> @Inject Codec codec;
> //...
> }
> Assuming that combined encoder/decoder classes like Base64 would implement
> that Codec interface, this could be directly bound to a combined
> encoder/decoder implementation.
> It would be nice if these interfaces were added and the existing codec
> classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
> modified to implement these new interfaces.
> I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13469207#comment-13469207
]
Mirko Raner commented on CODEC-158:
---
Correct, binary compatibility will not be affected.
Regarding the duplicate BinaryCodec class, here are some alternative names
(sorted according to my own preferences, most preferred one first):
- BinCodec (consistent with Codec suffix but breaks naming scheme related to
its encoder/decoder)
- BinaryEncoderDecoder (breaks Codec suffix scheme, but consistent with regards
to the prefix)
- CommonBinaryCodec
- IBinaryCodec (uses 'I' prefix for interface, which is not really used by
Apache Commons)
I'm open to any other suggestions as well.
The two additional alternatives that come to mind are (1) rename
org.apache.commons.codec.binary.BinaryCodec (a breaking API change; probably
not a good idea), and (2) remove the BinaryCodec interface without a
replacement (essentially trading in functionality for clarity).
Please let me know in which way I should fix this problem and I will submit an
updated patch.
> Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
> and decoder
> ---
>
> Key: CODEC-158
> URL: https://issues.apache.org/jira/browse/CODEC-158
> Project: Commons Codec
> Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Mirko Raner
>Priority: Minor
> Attachments: CODEC-158.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, there are no common interfaces that extend both the encoder and
> the decoder interfaces. This makes it hard to deal with a codec as a single
> entity and requires separate treatment of encoder and decoder parts.
> For example, let's say you want to develop a storage abstraction that uses an
> encoding. Right now, you would need to write
> class Storage
> {
> @Inject Encoder encoder;
> @Inject Decoder decoder;
> //...
> }
> In practice, encoder and decoder need to match, and most likely both encoder
> and decoder would be bound to the same implementation, like Base64 or
> URLCodec. Because of the lack of a common superinterface they need to be
> specified separately. There are some classes like BaseNCodec that can be used
> to unify some of the encoders and decoders, but they are too specific and
> restrictive.
> Ideally, I would like to write:
> class Storage
> {
> @Inject Codec codec;
> //...
> }
> Assuming that combined encoder/decoder classes like Base64 would implement
> that Codec interface, this could be directly bound to a combined
> encoder/decoder implementation.
> It would be nice if these interfaces were added and the existing codec
> classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
> modified to implement these new interfaces.
> I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirko Raner updated CODEC-158:
--
Attachment: CODEC-158.patch
Attached updated version of the patch.
I went with my preferred choice, BinCodec, as the new name of BinaryCodec. All
fully qualified class names that were previously necessary to resolve the
naming conflict were removed.
> Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
> and decoder
> ---
>
> Key: CODEC-158
> URL: https://issues.apache.org/jira/browse/CODEC-158
> Project: Commons Codec
> Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Mirko Raner
>Priority: Minor
> Attachments: CODEC-158.patch, CODEC-158.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, there are no common interfaces that extend both the encoder and
> the decoder interfaces. This makes it hard to deal with a codec as a single
> entity and requires separate treatment of encoder and decoder parts.
> For example, let's say you want to develop a storage abstraction that uses an
> encoding. Right now, you would need to write
> class Storage
> {
> @Inject Encoder encoder;
> @Inject Decoder decoder;
> //...
> }
> In practice, encoder and decoder need to match, and most likely both encoder
> and decoder would be bound to the same implementation, like Base64 or
> URLCodec. Because of the lack of a common superinterface they need to be
> specified separately. There are some classes like BaseNCodec that can be used
> to unify some of the encoders and decoders, but they are too specific and
> restrictive.
> Ideally, I would like to write:
> class Storage
> {
> @Inject Codec codec;
> //...
> }
> Assuming that combined encoder/decoder classes like Base64 would implement
> that Codec interface, this could be directly bound to a combined
> encoder/decoder implementation.
> It would be nice if these interfaces were added and the existing codec
> classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
> modified to implement these new interfaces.
> I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477611#comment-13477611
]
Mirko Raner commented on CODEC-158:
---
Can someone integrate this patch?
Please let me know if you have any further suggestions how we can improve this
contribution.
> Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
> and decoder
> ---
>
> Key: CODEC-158
> URL: https://issues.apache.org/jira/browse/CODEC-158
> Project: Commons Codec
> Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Mirko Raner
>Priority: Minor
> Attachments: CODEC-158.patch, CODEC-158.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, there are no common interfaces that extend both the encoder and
> the decoder interfaces. This makes it hard to deal with a codec as a single
> entity and requires separate treatment of encoder and decoder parts.
> For example, let's say you want to develop a storage abstraction that uses an
> encoding. Right now, you would need to write
> class Storage
> {
> @Inject Encoder encoder;
> @Inject Decoder decoder;
> //...
> }
> In practice, encoder and decoder need to match, and most likely both encoder
> and decoder would be bound to the same implementation, like Base64 or
> URLCodec. Because of the lack of a common superinterface they need to be
> specified separately. There are some classes like BaseNCodec that can be used
> to unify some of the encoders and decoders, but they are too specific and
> restrictive.
> Ideally, I would like to write:
> class Storage
> {
> @Inject Codec codec;
> //...
> }
> Assuming that combined encoder/decoder classes like Base64 would implement
> that Codec interface, this could be directly bound to a combined
> encoder/decoder implementation.
> It would be nice if these interfaces were added and the existing codec
> classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
> modified to implement these new interfaces.
> I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484759#comment-13484759
]
Mirko Raner commented on CODEC-158:
---
Hi Sebb,
I haven't seen any activity on this issue in a while.
Are there further improvements or changes you would like me to make, or is the
patch ready to be committed?
Thanks,
Mirko
> Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
> and decoder
> ---
>
> Key: CODEC-158
> URL: https://issues.apache.org/jira/browse/CODEC-158
> Project: Commons Codec
> Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Mirko Raner
>Priority: Minor
> Attachments: CODEC-158.patch, CODEC-158.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, there are no common interfaces that extend both the encoder and
> the decoder interfaces. This makes it hard to deal with a codec as a single
> entity and requires separate treatment of encoder and decoder parts.
> For example, let's say you want to develop a storage abstraction that uses an
> encoding. Right now, you would need to write
> class Storage
> {
> @Inject Encoder encoder;
> @Inject Decoder decoder;
> //...
> }
> In practice, encoder and decoder need to match, and most likely both encoder
> and decoder would be bound to the same implementation, like Base64 or
> URLCodec. Because of the lack of a common superinterface they need to be
> specified separately. There are some classes like BaseNCodec that can be used
> to unify some of the encoders and decoders, but they are too specific and
> restrictive.
> Ideally, I would like to write:
> class Storage
> {
> @Inject Codec codec;
> //...
> }
> Assuming that combined encoder/decoder classes like Base64 would implement
> that Codec interface, this could be directly bound to a combined
> encoder/decoder implementation.
> It would be nice if these interfaces were added and the existing codec
> classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
> modified to implement these new interfaces.
> I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (NET-497) ToNetASCIIInputStream skips LF at the end of the stream
Mirko Raner created NET-497:
---
Summary: ToNetASCIIInputStream skips LF at the end of the stream
Key: NET-497
URL: https://issues.apache.org/jira/browse/NET-497
Project: Commons Net
Issue Type: Bug
Components: Telnet, TFTP
Affects Versions: 3.1
Reporter: Mirko Raner
I have the following failing test case for ToNetASCIIInputStream:
public void testToNetASCIIInputStream() throws Exception
{
final Charset ASCII = Charset.forName("ASCII");
byte[] data = "Hello\nWorld\n".getBytes(ASCII);
InputStream source = new ByteArrayInputStream(data);
ToNetASCIIInputStream toNetASCII = new ToNetASCIIInputStream(source);
byte[] output = new byte[512];
int length = toNetASCII.read(output);
byte[] result = new byte[length];
System.arraycopy(output, 0, result, 0, length);
assertEquals('\r', result[length-2]);
assertEquals('\n', result[length-1]);
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-497) ToNetASCIIInputStream skips LF at the end of the stream
[
https://issues.apache.org/jira/browse/NET-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13563142#comment-13563142
]
Mirko Raner commented on NET-497:
-
Sorry, got all scrambled... please run it through the formatter first. Thanks!
> ToNetASCIIInputStream skips LF at the end of the stream
> ---
>
> Key: NET-497
> URL: https://issues.apache.org/jira/browse/NET-497
> Project: Commons Net
> Issue Type: Bug
> Components: Telnet, TFTP
>Affects Versions: 3.1
>Reporter: Mirko Raner
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I have the following failing test case for ToNetASCIIInputStream:
> public void testToNetASCIIInputStream() throws Exception
> {
> final Charset ASCII = Charset.forName("ASCII");
> byte[] data = "Hello\nWorld\n".getBytes(ASCII);
> InputStream source = new ByteArrayInputStream(data);
> ToNetASCIIInputStream toNetASCII = new ToNetASCIIInputStream(source);
> byte[] output = new byte[512];
> int length = toNetASCII.read(output);
> byte[] result = new byte[length];
> System.arraycopy(output, 0, result, 0, length);
> assertEquals('\r', result[length-2]);
> assertEquals('\n', result[length-1]);
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566287#comment-13566287
]
Mirko Raner commented on CODEC-158:
---
Introducing a common interface for encoder/decoder and converting the existing
hierarchy to generics are orthogonal issues, in my view. As such, I propose to
solve them separately and not intermix these two issues.
A common superinterface for encoders and decoders is useful with and without
generics, and, as far as I can see, it does not impede the introduction of
generics at a later point.
CODEC-158 is strictly about the common superinterface for encoders and
decoders. I agree that, going forward, genericized encoders/decoders would be
extremely useful, but we should discuss this as a separate issue.
> Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
> and decoder
> ---
>
> Key: CODEC-158
> URL: https://issues.apache.org/jira/browse/CODEC-158
> Project: Commons Codec
> Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Mirko Raner
>Priority: Minor
> Attachments: CODEC-158.patch, CODEC-158.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, there are no common interfaces that extend both the encoder and
> the decoder interfaces. This makes it hard to deal with a codec as a single
> entity and requires separate treatment of encoder and decoder parts.
> For example, let's say you want to develop a storage abstraction that uses an
> encoding. Right now, you would need to write
> class Storage
> {
> @Inject Encoder encoder;
> @Inject Decoder decoder;
> //...
> }
> In practice, encoder and decoder need to match, and most likely both encoder
> and decoder would be bound to the same implementation, like Base64 or
> URLCodec. Because of the lack of a common superinterface they need to be
> specified separately. There are some classes like BaseNCodec that can be used
> to unify some of the encoders and decoders, but they are too specific and
> restrictive.
> Ideally, I would like to write:
> class Storage
> {
> @Inject Codec codec;
> //...
> }
> Assuming that combined encoder/decoder classes like Base64 would implement
> that Codec interface, this could be directly bound to a combined
> encoder/decoder implementation.
> It would be nice if these interfaces were added and the existing codec
> classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
> modified to implement these new interfaces.
> I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-497) ToNetASCIIInputStream skips LF at the end of the stream
[
https://issues.apache.org/jira/browse/NET-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566929#comment-13566929
]
Mirko Raner commented on NET-497:
-
O.K., I see what you're saying. This behavior seems to trigger a failure in our
application, though. I'll double-check to see if ToNetASCIIInputStream is
indeed the culprit and if I extracted the test case correctly.
> ToNetASCIIInputStream skips LF at the end of the stream
> ---
>
> Key: NET-497
> URL: https://issues.apache.org/jira/browse/NET-497
> Project: Commons Net
> Issue Type: Bug
> Components: Telnet, TFTP
>Affects Versions: 3.1
>Reporter: Mirko Raner
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I have the following failing test case for ToNetASCIIInputStream:
> {noformat}
> public void testToNetASCIIInputStream() throws Exception
> {
> final Charset ASCII = Charset.forName("ASCII");
> byte[] data = "Hello\nWorld\n".getBytes(ASCII);
> InputStream source = new ByteArrayInputStream(data);
> ToNetASCIIInputStream toNetASCII = new ToNetASCIIInputStream(source);
> byte[] output = new byte[512];
> int length = toNetASCII.read(output);
> byte[] result = new byte[length];
> System.arraycopy(output, 0, result, 0, length);
> assertEquals('\r', result[length-2]);
> assertEquals('\n', result[length-1]);
> }
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-158) Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder and decoder
[
https://issues.apache.org/jira/browse/CODEC-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587495#comment-13587495
]
Mirko Raner commented on CODEC-158:
---
It seems like everybody had a chance to voice their opinion on this feature
now. I'm not too familiar with how decisions are made at Apache Commons, so my
next question is how we drive this forward. I'm happy to accept any outcome
here, but to me it seems that this issue has been in limbo for long enough now.
Is there any other information I can provide to resolve this?
> Add Codec, StringCodec, and BinaryCodec interfaces that extend both encoder
> and decoder
> ---
>
> Key: CODEC-158
> URL: https://issues.apache.org/jira/browse/CODEC-158
> Project: Commons Codec
> Issue Type: Improvement
>Affects Versions: 1.7
>Reporter: Mirko Raner
>Priority: Minor
> Attachments: CODEC-158.patch, CODEC-158.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Currently, there are no common interfaces that extend both the encoder and
> the decoder interfaces. This makes it hard to deal with a codec as a single
> entity and requires separate treatment of encoder and decoder parts.
> For example, let's say you want to develop a storage abstraction that uses an
> encoding. Right now, you would need to write
> class Storage
> {
> @Inject Encoder encoder;
> @Inject Decoder decoder;
> //...
> }
> In practice, encoder and decoder need to match, and most likely both encoder
> and decoder would be bound to the same implementation, like Base64 or
> URLCodec. Because of the lack of a common superinterface they need to be
> specified separately. There are some classes like BaseNCodec that can be used
> to unify some of the encoders and decoders, but they are too specific and
> restrictive.
> Ideally, I would like to write:
> class Storage
> {
> @Inject Codec codec;
> //...
> }
> Assuming that combined encoder/decoder classes like Base64 would implement
> that Codec interface, this could be directly bound to a combined
> encoder/decoder implementation.
> It would be nice if these interfaces were added and the existing codec
> classes (BaseNCodec, Hex, QCodec, QuotedPrintableCodec, URLCodec) could be
> modified to implement these new interfaces.
> I'm happy to contribute a patch if there is interest in this feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
