[jira] [Commented] (MATH-653) Rename AbstractRealVector to RealVector
[
https://issues.apache.org/jira/browse/MATH-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092656#comment-13092656
]
Sébastien Brisard commented on MATH-653:
Gilles,
I would favor inlining.
I'm still working on iterative solvers, so if you want, I can take care of
{{RealLinearOperator}} (which was added for this special purpose). Indeed,
following what you've just done {{double[] operate(double[] x)}} should
probably be removed from this class. Question is: should it also disappear from
the daughter class {{AbstractRealMatrix}}? As an aside, is there any plan to
rename {{AbstractRealMatrix}} to {{RealMatrix}}?
Since I'm still working on the interface of linear solvers, I'll remove the
method {{solve(RealLinearOperator, double[], double[]}}, and keep only
{{solve(RealLinearOperator, RealVector, RealVector}} before I submit anything.
I guess the next step (setting apart the refactoring of
RealMatrix/AbstractRealMatrix in the same fashion) would be to look into
{{DecompositionSolver}} as well, and remove any methods taking {{double[]}} as
an input.
Rename AbstractRealVector to RealVector
---
Key: MATH-653
URL: https://issues.apache.org/jira/browse/MATH-653
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Fix For: 3.0
AbstractRealVector is the only implementation of the RealVector interface.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (NET-421) Problem connecting to TLS/SSL SMTP server using explicit mode
Problem connecting to TLS/SSL SMTP server using explicit mode
-
Key: NET-421
URL: https://issues.apache.org/jira/browse/NET-421
Project: Commons Net
Issue Type: Bug
Components: SMTP
Affects Versions: 3.0
Reporter: Oliver Saggau
Priority: Critical
Just tried to send an email through gmail servers by doing the following:
AuthenticatingSMTPClient client = new AuthenticatingSMTPClient();
client.connect(smtp.gmail.com, 587); // reply: 220 220 mx.google.com ESMTP
client.login(); // reply: 250 250 mx.google.com at your service
client.execTLS(); // reply: 220 2.0.0 Ready to start TLS
client.auth(AUTH_METHOD.PLAIN, username, password); // exception
...
Unfortunality after execTLS() I get a MalformedServerReplyException. I looked
at the SMTPSClient source code and found out that the reader/writer are wrong
after execTLS() got called. The performSSLNegotiation() method sets _input_ and
_output_ to the new input/output streams from SSLSocket, but the reader/writer
are still pointing to the values set inside _connectAction_().
Possible fix for this issue:
{code}public boolean execTLS() throws SSLException, IOException
{
if (!SMTPReply.isPositiveCompletion(sendCommand(STARTTLS)))
{
return false;
//throw new SSLException(getReplyString());
}
performSSLNegotiation();
_reader = new CRLFLineReader(new InputStreamReader(_input_, encoding));
_writer = new BufferedWriter(new OutputStreamWriter(_output_,
encoding));
return true;
}{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-421) Problem connecting to TLS/SSL SMTP server using explicit mode
[
https://issues.apache.org/jira/browse/NET-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Saggau updated NET-421:
--
Description:
Just tried to send an email through gmail servers by doing the following:
{code}AuthenticatingSMTPClient client = new AuthenticatingSMTPClient();
client.connect(smtp.gmail.com, 587); // reply: 220 220 mx.google.com ESMTP
client.login(); // reply: 250 250 mx.google.com at your service
client.execTLS(); // reply: 220 2.0.0 Ready to start TLS
client.auth(AUTH_METHOD.PLAIN, username, password); // exception
...{code}
Unfortunality after execTLS() I get a MalformedServerReplyException. I looked
at the SMTPSClient source code and found out that the reader/writer are wrong
after execTLS() got called. The performSSLNegotiation() method sets _input_ and
_output_ to the new input/output streams from SSLSocket, but the reader/writer
are still pointing to the values set inside _connectAction_().
Possible fix for this issue:
{code}public boolean execTLS() throws SSLException, IOException
{
if (!SMTPReply.isPositiveCompletion(sendCommand(STARTTLS)))
{
return false;
//throw new SSLException(getReplyString());
}
performSSLNegotiation();
_reader = new CRLFLineReader(new InputStreamReader(_input_, encoding));
_writer = new BufferedWriter(new OutputStreamWriter(_output_,
encoding));
return true;
}{code}
was:
Just tried to send an email through gmail servers by doing the following:
AuthenticatingSMTPClient client = new AuthenticatingSMTPClient();
client.connect(smtp.gmail.com, 587); // reply: 220 220 mx.google.com ESMTP
client.login(); // reply: 250 250 mx.google.com at your service
client.execTLS(); // reply: 220 2.0.0 Ready to start TLS
client.auth(AUTH_METHOD.PLAIN, username, password); // exception
...
Unfortunality after execTLS() I get a MalformedServerReplyException. I looked
at the SMTPSClient source code and found out that the reader/writer are wrong
after execTLS() got called. The performSSLNegotiation() method sets _input_ and
_output_ to the new input/output streams from SSLSocket, but the reader/writer
are still pointing to the values set inside _connectAction_().
Possible fix for this issue:
{code}public boolean execTLS() throws SSLException, IOException
{
if (!SMTPReply.isPositiveCompletion(sendCommand(STARTTLS)))
{
return false;
//throw new SSLException(getReplyString());
}
performSSLNegotiation();
_reader = new CRLFLineReader(new InputStreamReader(_input_, encoding));
_writer = new BufferedWriter(new OutputStreamWriter(_output_,
encoding));
return true;
}{code}
Problem connecting to TLS/SSL SMTP server using explicit mode
-
Key: NET-421
URL: https://issues.apache.org/jira/browse/NET-421
Project: Commons Net
Issue Type: Bug
Components: SMTP
Affects Versions: 3.0
Reporter: Oliver Saggau
Priority: Critical
Just tried to send an email through gmail servers by doing the following:
{code}AuthenticatingSMTPClient client = new AuthenticatingSMTPClient();
client.connect(smtp.gmail.com, 587); // reply: 220 220 mx.google.com ESMTP
client.login(); // reply: 250 250 mx.google.com at your service
client.execTLS(); // reply: 220 2.0.0 Ready to start TLS
client.auth(AUTH_METHOD.PLAIN, username, password); // exception
...{code}
Unfortunality after execTLS() I get a MalformedServerReplyException. I looked
at the SMTPSClient source code and found out that the reader/writer are wrong
after execTLS() got called. The performSSLNegotiation() method sets _input_
and _output_ to the new input/output streams from SSLSocket, but the
reader/writer are still pointing to the values set inside _connectAction_().
Possible fix for this issue:
{code}public boolean execTLS() throws SSLException, IOException
{
if (!SMTPReply.isPositiveCompletion(sendCommand(STARTTLS)))
{
return false;
//throw new SSLException(getReplyString());
}
performSSLNegotiation();
_reader = new CRLFLineReader(new InputStreamReader(_input_, encoding));
_writer = new BufferedWriter(new OutputStreamWriter(_output_,
encoding));
return true;
}{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-653) Rename AbstractRealVector to RealVector
[
https://issues.apache.org/jira/browse/MATH-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13092841#comment-13092841
]
Gilles commented on MATH-653:
-
{quote}
I would favor inlining.
{quote}
Done in revision 1162800.
{quote}
I can take care of RealLinearOperator [...]
{quote}
OK.
{quote}
any plan to rename AbstractRealMatrix to RealMatrix?
{quote}
That certainly should be done. ;)
Maybe better wait for the conclusion of the ongoing discussion on what to
remove/rename in that interface/class...
{quote}
DecompositionSolver [...] remove any methods taking double[] as an input.
{quote}
You are welcome to do it.
Rename AbstractRealVector to RealVector
---
Key: MATH-653
URL: https://issues.apache.org/jira/browse/MATH-653
Project: Commons Math
Issue Type: Task
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Fix For: 3.0
AbstractRealVector is the only implementation of the RealVector interface.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-340) New component for lang -- summarizer
[ https://issues.apache.org/jira/browse/SANDBOX-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13093087#comment-13093087 ] Liviu Tudor commented on SANDBOX-340: - Thanks everyone for your help with this -- I have sent the email as suggested so we'll see what happens. Do I need to do anything now with this issue? New component for lang -- summarizer Key: SANDBOX-340 URL: https://issues.apache.org/jira/browse/SANDBOX-340 Project: Commons Sandbox Issue Type: New Feature Components: Functor Reporter: Liviu Tudor Priority: Minor Labels: features, newbie Attachments: patch_summarizer.diff Hi, I'm creating this as a patch request but I guess really initially I wanted to verify with everyone that commons lang is the place for this class hierarchy I'm proposing -- and if not please suggest whether it would be more appropriate to submit this to collections or one of the other Commons projects. (Or I accept as well the fact that it might not be good enough for any of the commons projects in which case please just let me know so I won't try to create new issues around this in the future.) Basically I've come across a pattern I find myself using a lot in my applications where I want a quick (and not so dirty) way of monitoring certain things in the application -- for instance, I want as a quick healthcheck a page to tell me how many requests we process over a 1 minute interval or so. While one can implement complex monitoring systems to achieve the same, a lot of the times, simply the fact that the number of successful transactions per minute goes down to 50% (after an application upgrade for instance) is a clear indicator to me that something isn't right so I can start investigating straight away and not wait for our monitoring systems to kick in one hour later or so and alert us of this. As such I have developed this component which I have called Summarizer (purely as my initial request was just to sum up some numbers over a period of time and reset it regularly -- but as my javadoc comments state, of course this doesn't have to be a simple arithmetic sum and can be extended to other operations). The diff I'm proposing here contains the base class and an example of the class using integers which just sums them up -- which is as I said the kind of implementation that I have found myself implementing a lot in my apps. I appreciate that the classes are not completely finished and there are no unit tests yet -- and that is because as I said at this stage I am trying to figure out whether this component would fit into the Commons Lang component or it would be more appropriate to commit this somewhere else. I would appreciate your input/comments on this so I know whether i'm on the right track on committing this here or should I move it elsewhere; I accept that perhaps the package names and the class names are not the best, and am willing to discuss with your main committers around this -- if this proves to be a valid component for commons. If you decide this is a good idea to proceed with then I can start adding unit tests and more comments/javadocs around it to make this into a usable class hierarchy. As suggested by your FAQ's I've created a diff from the root of the folder -- if it helps more if I just provide the 2 classes I can do so too -- just let me know and I can send you a zip with the 2 classes alone or so. Looking forward to your comments on this, Liv -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-53) Global Update of Chain - Generics, JDK 1.5, Update Dependency Versions
[
https://issues.apache.org/jira/browse/CHAIN-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13093163#comment-13093163
]
Matt Benson commented on CHAIN-53:
--
Hmm, I just noticed another rather large change incorporated in the patch, at
least in its most recent version, though I assume that I simply overlooked it
before. {{org.apache.commons.chain.impl.ContextBase}}, and through it, its
various provided subclasses, have been changed to extend {{ConcurrentHashMap}}
instead of {{HashMap}}. I can appreciate that concurrency might be an issue in
this arena, and I don't have a great concern over the internal APIs of a given
{{ContextBase}} user subclass in the sense that some method an implementation
formerly depended on from {{HashMap}} is no longer available due to the
modified inheritance hierarchy. However, I do note a glaring difference of
{{CHM}} vs. {{HM}}: the latter accepts {{null}} keys and values, while the
former does not. While it is very possibly the case that neither {{null}} keys
nor values make sense for chain context implementations, thereby placing this
break in backward compatibility into the harmless category, this break is
worth noting and possibly discussing.
Global Update of Chain - Generics, JDK 1.5, Update Dependency Versions
--
Key: CHAIN-53
URL: https://issues.apache.org/jira/browse/CHAIN-53
Project: Commons Chain
Issue Type: Improvement
Reporter: Elijah Zupancic
Assignee: Simone Tripodi
Labels: newbie, patch
Attachments: CHAIN-53_2011-08-25.patch
As posted in the mailing list, I've done this work outside of an offical
branch.
In this patch:
* Global upgrade to the JDK 1.5
* Added @Override annotations
* Upgraded to the Servlet 2.5 API
* Upgraded to the Faces 2.1 API
* Upgraded to the Portlet 2.0 API
* Upgraded the Maven Parent POM version
* Added generics support to Command so that Command's API looks like:
public interface CommandT extends Context {
...
boolean execute(T context) throws Exception;
}
The only incompatibility with the existing API is in:
org.apache.commons.chain.web.servlet.ServletHeaderValuesMap on line 97.
Previously the API was returning SetEntryString, EnumerationString when
by all indications it actually should have been returning SetEntryString,
String[]. I believe that I fixed a previously undiscovered bug here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-53) Global Update of Chain - Generics, JDK 1.5, Update Dependency Versions
[
https://issues.apache.org/jira/browse/CHAIN-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13093194#comment-13093194
]
Elijah Zupancic commented on CHAIN-53:
--
@Matt Benson
Thanks for catching that. For some reason, that implementation detail slipped
my mind. I will write a unit test to see if the existing API supports NULL
keys. Since the context base uses JavaBeanUtils to map keys to class setters /
getters, it may very well not support null keys.
Global Update of Chain - Generics, JDK 1.5, Update Dependency Versions
--
Key: CHAIN-53
URL: https://issues.apache.org/jira/browse/CHAIN-53
Project: Commons Chain
Issue Type: Improvement
Reporter: Elijah Zupancic
Assignee: Simone Tripodi
Labels: newbie, patch
Attachments: CHAIN-53_2011-08-25.patch
As posted in the mailing list, I've done this work outside of an offical
branch.
In this patch:
* Global upgrade to the JDK 1.5
* Added @Override annotations
* Upgraded to the Servlet 2.5 API
* Upgraded to the Faces 2.1 API
* Upgraded to the Portlet 2.0 API
* Upgraded the Maven Parent POM version
* Added generics support to Command so that Command's API looks like:
public interface CommandT extends Context {
...
boolean execute(T context) throws Exception;
}
The only incompatibility with the existing API is in:
org.apache.commons.chain.web.servlet.ServletHeaderValuesMap on line 97.
Previously the API was returning SetEntryString, EnumerationString when
by all indications it actually should have been returning SetEntryString,
String[]. I believe that I fixed a previously undiscovered bug here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-341) [functor] New components: summarize and aggregate
[ https://issues.apache.org/jira/browse/SANDBOX-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liviu Tudor updated SANDBOX-341: Attachment: commons-functor-aggregate+summarizer.zip Diff taken against trunk on 29/Aug/2011 (about midnight in UK :) [functor] New components: summarize and aggregate - Key: SANDBOX-341 URL: https://issues.apache.org/jira/browse/SANDBOX-341 Project: Commons Sandbox Issue Type: Improvement Components: Functor Environment: JDK 1.6.0_25 but should work with any JDK 5+ (possibly 1.4 though I haven't tested). Reporter: Liviu Tudor Priority: Minor Labels: features Attachments: commons-functor-aggregate+summarizer.zip This is the next step from https://issues.apache.org/jira/browse/SANDBOX-340 -- as instructed I'm finally hoping to get the code in the right place and hopefully this is something that the functor component could do with. Whereas initially I just started with the summarizer component, I have added now the second one, the aggregator as they are somehow related. If this code proves to be useful to functor in any way, it would actually be good to get some feedback on these 2 to see if the class hierarchy can in fact be changed to share some common functionality as I feel (probably due to the similar needs that lead to writing/using these components) that somehow they should share a common base. In brief, the 2 components: * aggregator: this just allows for data to be aggregated in a user defined way (e.g. stored in a list for the purpose of averaging, computing the arithmetic median etc). The classes provided actually offer the implementation for storing data in a list and computing the above-mentioned values or summing up everything. * timed summarizer: this is another variation of the aggreator, however, it adds the idea of regular flushes, so based on a timer it will reset the value and start summing/aggregating the data again. Rather than using an aggregator which would store the whole data series (possibly for applying more complex formulas), this component just computes on the fly on each request the formula and stores the result of it. (Which does mean things like computing arithmetic mean, median etc would be difficult to compute without knowing upfront how many calls will be received -- i.e. how many elements we will be required to summarize/aggregate.) So the memory footprint of running this is much smaller -- even though, as I said, it achieves similar results. I have only provided a summarizer which operates on integers, but obviously others for float, double etc can be created if we go ahead with this design. Hopefully the above make sense; this code has resulted from finding myself writing similar components to these a few times and because it's always been either one type (e.g. aggregator) or another (summarizer) I haven't given quite possibly enough thought to the class design to join these 2. Also, unfortunately, the time I sat down to make these components a bit more general and submitted issue 340 was nearly 3 months ago so I'm trying to remember myself all the ideas I had at a time so bear with me please if these are still a bit fuzzy :) However, if you can make use of these I'm quite happy to elaborate on areas that are unclear and obviously put some effort into getting these components to the standards required to put these into a release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-341) [functor] New components: summarize and aggregate
[functor] New components: summarize and aggregate - Key: SANDBOX-341 URL: https://issues.apache.org/jira/browse/SANDBOX-341 Project: Commons Sandbox Issue Type: Improvement Components: Functor Environment: JDK 1.6.0_25 but should work with any JDK 5+ (possibly 1.4 though I haven't tested). Reporter: Liviu Tudor Priority: Minor Attachments: commons-functor-aggregate+summarizer.zip This is the next step from https://issues.apache.org/jira/browse/SANDBOX-340 -- as instructed I'm finally hoping to get the code in the right place and hopefully this is something that the functor component could do with. Whereas initially I just started with the summarizer component, I have added now the second one, the aggregator as they are somehow related. If this code proves to be useful to functor in any way, it would actually be good to get some feedback on these 2 to see if the class hierarchy can in fact be changed to share some common functionality as I feel (probably due to the similar needs that lead to writing/using these components) that somehow they should share a common base. In brief, the 2 components: * aggregator: this just allows for data to be aggregated in a user defined way (e.g. stored in a list for the purpose of averaging, computing the arithmetic median etc). The classes provided actually offer the implementation for storing data in a list and computing the above-mentioned values or summing up everything. * timed summarizer: this is another variation of the aggreator, however, it adds the idea of regular flushes, so based on a timer it will reset the value and start summing/aggregating the data again. Rather than using an aggregator which would store the whole data series (possibly for applying more complex formulas), this component just computes on the fly on each request the formula and stores the result of it. (Which does mean things like computing arithmetic mean, median etc would be difficult to compute without knowing upfront how many calls will be received -- i.e. how many elements we will be required to summarize/aggregate.) So the memory footprint of running this is much smaller -- even though, as I said, it achieves similar results. I have only provided a summarizer which operates on integers, but obviously others for float, double etc can be created if we go ahead with this design. Hopefully the above make sense; this code has resulted from finding myself writing similar components to these a few times and because it's always been either one type (e.g. aggregator) or another (summarizer) I haven't given quite possibly enough thought to the class design to join these 2. Also, unfortunately, the time I sat down to make these components a bit more general and submitted issue 340 was nearly 3 months ago so I'm trying to remember myself all the ideas I had at a time so bear with me please if these are still a bit fuzzy :) However, if you can make use of these I'm quite happy to elaborate on areas that are unclear and obviously put some effort into getting these components to the standards required to put these into a release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
