Re: [commons-cli] handling properties files as default . . .

[Albretch Mueller]

On 2/10/19, sebb  wrote:
>
> Unfortunately CLI parsing *is* quite complicated.
>
> For example, how do you handle missing parameters?
> Assume -a, -b, -c all take one parameter.
> How do you parse:
>
> $ sample -a one -b -c two
>
> Is that:
> -a => one
> -b => -c
> rest: two
>
> Or does that cause a parsing error, because -b has no parameter?
>
> What if -b has an optional parameter?
> Does that mean -c is set to two?

 IMO, if a command line parser finds a line sequence like:

$ sample -a one -b -c two

 it should print a warning to System.err and return;

 -a:one
 -b:null
 -c:two

On 2/11/19, Remko Popma  wrote:
> Picocli's value proposition is that it eliminates boilerplate code from the
> application.

 But how, by introducing Picocli's own boilerplate code? Did you look
yourself at the sample Picocli code you posted?

 From the little corner from which I see reality:

 1) All you need is one line of code in your main start up method
(literally, or if you want to nitpick 3):

  HashMap HM2SKdCtxt = null;
  try{ HM2SKdCtxt = (new
JRIContext00()).getJRIContext(System.currentTimeMillis(), aArgs); }
   catch(IOException IOX){ IOX.printStackTrace(System.err); }

 2) JRIContext (less than 900 lines of code):

 2.1) looks into a global file at the well-known, accessible location:

  new File((new File(System.getProperty("user.home"))),
".jricontext.default.properties");

 that global property files is read in as a plain java properties file
encoded in ISO 8859-1

 2.2) looks into the local directory (System.getProperty("user.dir"))
for all files patterned as:

 _jricontext<_encoding>.properties

 2.2.1) sort them by last modified
 2.2.2) gives user (2?) seconds (to be implemented using a GUI) to
choose the file to be read with the encoding she means

 That local _jricontext<_encoding>.properties is then
read in using an InputStreamReader with the encoding specified right
in the name.

 2.3) all global and local settings are "put" in a hashmap, local
settings take precedence over global ones

 2.4) JRIContext then parses the command line as its third and last stage

 2.5) all command line parameters, global and local settings are "put"
in a hashmap. command line parameters take precedence over global and
local settings (this is handy when you need to do a quick test)

 2.6) There are three baseline parameters which for sanity and
security reasons can't be set as part of the java running instance
either in the properties files or command prompt. They are just
included in JRIContext output for the user to avail herself of such
values if she so decides:

 2.6.1) current running's class name which key is: "--jri-klass-name"
 2.6.2) start up time in milliseconds (used for log files
redirection): "--jri-startup-time-ms"
 2.6.3) the global and local properties file (which are hardcoded):
"--jri-local-props-fl"

 2.7) using command objects, JRIContext checks the sanity of all input
data before setting the values

 2.8) you can in turn script the properties with any value internally
defined either as System.getProperties() or System.getEnv(). Say if
you are testing some code for which you would like System.out and
System.err to indicated in the suffix the "java.runtime.version" and
"os.version" as returned by System.getProperties(), and
"XDG_CURRENT_DESKTOP" and "XDG_SEAT" by System.getEnv(), you would
just indicated in your properties file:

--jri-log-files-suffix:
("java.runtime.version")_("os.version")_("XDG_CURRENT_DESKTOP")_("XDG_SEAT")
~
 Check out JRIContext:

 https://sourceforge.net/projects/jricontext/files/JRIX/

 I just posted all files there as a proof of concept, I coded the
whole things pretty much in one go. I haven't had the time to take a
second look at it to refine, clean up that code, create javadocs ...

 I dropped my initial requirement/ideations to use as metasyntax the
extended Backus Naur form (ISO/IEC
14977) and not a HashMap, but just a
HashMap is returned by  jricontext (users should take
care of parsing a, say, pipe delimited String into an array String[]).

 Users are not forced to enter command line arguments in a strict way
and order and they are able to chose the character encoding of the
data they will be feeding into a program.

 I don't know if apache commons accepts "alternate realities", but I
would clean all that code up, make it play better with apache commons
and maintain it.

 I find a bit annoying that java hasn't offered such an utility:
java.util.jricontext?

 lbrtchx

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [email] Email sent with commons email having long filename attachments, show problems in Outlook

[Siegfried Goeschl]

Hi Raffaele,

Had a quick look at the code - the code directly uses the JDK MimeUtility class 
to implement the folding. And doing something differently is hard to find out 
since there are many email clients out there - and actually following the RFC 
is quite hard

Thanks in advance, 

Siegfried Goeschl



> On 06.02.2019, at 14:05, Raffaele Gambelli  wrote:
> 
> Hi all,
> 
> this is probably a known issue, Outlook is not fully conform to RFC 2231 so 
> it's unable to parse long filename attachments, this happens when sender 
> applies RFC 822 folding rules, so for example a filename 
> "CANALI+GIOVANNI+SRL+-+NOTA+PROT.+0001461+DEL+04.02.2019.pdf.p7m" once sent 
> (via commons email) becomes:
> 
> Content-Type: application/pkcs7-signature;
> name*0=CANALI+GIOVANNI+SRL+-+NOTA+PROT.+0001461+DEL+04.02.2019.pdf.;
> name*1=p7m
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> filename*0=CANALI+GIOVANNI+SRL+-+NOTA+PROT.+0001461+DEL+04.02.2019.pdf.;
> filename*1=p7m
> 
> This problem has been present in Outlook for many years, I could suppose 
> Microsoft doesn't think to fix it, maybe they think it's not an issue, I 
> really don't know.
> 
> What I would like to know is if with "commons email" exists the possibility 
> to avoid folding of header parameter names, besides that I would like to know 
> your opinion if what I've just said is right or if it could bring problems on 
> some other different clients.
> 
> Thanks, best regards
> 
> Some useful references:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=309566
> 
> https://tools.ietf.org/html/rfc2231
> [https://westpole.it/firma/logo.png]
> 
> Raffaele Gambelli
> WebRainbow(r) Software Developer
> 
> P +39 051 8550 576
> M #
> E r.gambe...@westpole.it
> W https://westpole.webex.com/meet/R.Gambelli
> A Via Ettore Cristoni, 84 - 40030 Casalecchio di Reno
> 
> [https://westpole.it/firma/sito.png]  
> [https://westpole.it/firma/twitter.png]    
> [https://westpole.it/firma/facebook.png] 
>    
> [https://westpole.it/firma/linkedin.png] 
> 
> 
> 
> This email for the D.lgs.196/2003 (Privacy Code) and European Regulation 
> 679/2016/UE (GDPR) may contain confidential and/or privileged information for 
> the exclusive use of the intended recipient. Any review or distribution by 
> others is strictly prohibited. If you are not the intended recipient, you 
> must not use, copy, disclose or take any action based on this message or any 
> information here. If you have received this email in error, please contact us 
> (email:priv...@westpole.it) by reply email and delete all copies. Legal 
> privilege is not waived because you have read this email. Thank you for your 
> cooperation.
> 
> 
> [https://westpole.it/firma/ambiente.png] Please consider the environment 
> before printing this email
> 
> 
> -
> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
> For additional commands, e-mail: user-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[ANNOUNCE] Apache Commons Codec 1.12 Released.

[Rob Tompkins]

The Apache Commons team is pleased to announce the release of Commons Codec
1.12.

Apache Commons Codec (TM) software provides implementations of common
encoders and decoders such as Base64, Hex, Phonetic and URLs.

Details of the changes and bug fixes in this release can be found in the
release notes:
  http://www.apache.org/dist/commons/codec/RELEASE-NOTES.txt

For information on Commons CODEC please visit the CODEC website:
  http://commons.apache.org/codec/

Commons Codec can be downloaded from the following page:
 http://commons.apache.org/codec/download_codec.cgi

Best regards,
Rob Tompkins
on behalf of the Apache Commons community

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org