Is every Folder a UIDFolder for JavaMail IMAP - jakarta-mail

Using JavaMail with an imaps store, calling store#getFolder returns a Folder interface.
For IMAP, will this ALWAYS be a concrete IMAPFolder and hence a UIDFolder?
Or are there scenarios where it might be a different concrete class, and hence not an IMAPFolder? i.e. am I safe to blindly cast to UIDFolder for IMAP?

Using the included protocol providers, imaps always returns an IMAPFolder, which is always a UIDFolder.

Related

Option 'getWithBody' of HttpComponent is not working in Apache Camel

The version of Apache Camel is 2.18.1
In documentation for 2.x, https://camel.apache.org/components/2.x/http4-component.html, getWithBody and deleteWithBody options as query parameters are provided.
deleteWithBody (producer) : Whether the HTTP DELETE should include the message body or not. By default HTTP DELETE do not include any HTTP body. However in some rare cases users may need to be able to include the message body. Default: false
getWithBody (producer) : Whether the HTTP GET should include the message body or not. By default HTTP GET do not include any HTTP body. However in some rare cases users may need to be able to include the message body. Default false
But when I concatenate one of these 2 parameters at the end of the endpoint URI, it's not recognized as an option. Instead, it's passed to the endpoint as an ordinary query parameter, while other query parameter options are treated as component options and not forwarded to the endpoint.
When I inspect the source code, I see that options are recognized by matching with the fields and methods of HttpEndpoint (org.apache.camel.component.http4) and HttpCommonEndpoint (org.apache.camel.http.common) classes. getWithBody and deleteWithBody fields doesn't exist in these classes while other options can be found among the fields of these classes.
Can I assume that the documentation is wrong? If so, how can I achieve to send body with HttpComponent(Http4Component) of Camel while the http method is GET or DELETE?
Option deleteWithBody was introduced in Apache Camel 2.19.0. See CAMEL-10916.
Option getWithBody was introduced in Apache Camel 3.0.0 and backported to 2.25.0. See CAMEL-14118.
For such old version use docs archived on github, it is not published on website - https://github.com/apache/camel/blob/camel-2.18.x/components/camel-http4/src/main/docs/http4-component.adoc
You need to update to newer version or implement custom component overriding some methods from HTTP4 component. There is no option to enable this OOTB in 2.18.1.
i agree with the answer given by #Bedla.
to add something additional this is what we did .
We checked the code and debugged - this allowed us to realize that at a point were camel interacts it drops the body if a GET Call has a one. it will be send as a normal GET Request because Camel version 3.x.x only supports it.
we tried different ways to forcefully add the body. that was also failed because what ever we add will be discarded by camel.
we were using camel v2.22.1 at the time. going to a higher version such as camel 3.x.x will be a big leap since there are multiple changes that will be included , so lucky for us camel team back ported this ability to send the GET Request with the Body (from here on getWithBody) to camel v2.25.0
coding level changes :
Append getWithBody=true to the Request URL
Updated camel Modules
camel-core-2.25.0.jar
camel-cxf-transport-2.25.0.jar
camel-cxf-2.25.0.jar
camel-core-xml-2.25.0.jar
camel-http-common-2.25.0.jar
camel-jaxb-2.25.0.jar
camel-spring-2.25.0.jar
camel-soap-2.25.0.jar
camel-cdi-2.25.0.jar
camel-jdbc-2.25.0.jar
camel-http4-2.25.0.jar
****special note ****
Note that under each folder location, there is a modules.xml file. You need yo open that and change the jar file version number to the one you want to use. in this case 2.25.0
That’s it and Happy Coding !

AppEngine/Go: urlfetch vs http.Get, etc

Is it necessary to use urlfetch under AppEngine? I'd like to write a generic client to use with one of my services, but, if urlfetch is required from AppEngine, how can I write a generic client for use both from outside AppEngine (for the public) and inside AppEngine (for my other services) without having to write two different versions or passing some kind of factory that produces the right implementation?
The application should pass an http.Client to your generic client. It can either be a parameter to the function or passed through a context as done in the oauth2 package.
If the application does not provide a http.Client through one of these mechanisms (nil arg or no value in context), then use the default client.

google managed-VMs specify instance in URL

I use google managed-VMs. My module has several instances. I need to perform a HTTP call on each of these instances. Hence, I would like to know if there is a way to specify the recipient instance in the URL.
For instance I tried: http://<instance-name>.<module-name>.<project-name>.appspot.com/ without success.
You're missing a <version-name> in there:
http://<instance-name>.<version-name>.<module-name>.<project-name>.appspot.com
See https://cloud.google.com/appengine/docs/python/modules/#Python_Application_hierarchy for more details (this is the page for Python, but it applies across-the-board.

Go Rest API on GAE

I'm pretty new to go and I want to build a CRUD rest API on GAE without views just simple JSON Rest API.
There is allot of frameworks out there,
go-http-routing-benchmark.
But I'm not sure which one will be most suitable for GAE.
My main concern is how to handle a safe and secure session .
As mentioned in a comment, you can start with the Go standard library, and only utilize 3rd party libs if you reach a point when the standard library is not sufficient for you (which point you may never reach).
If your clients are not browsers (you said you don't want any views) but any other arbitrary HTTP clients, an HTTP session may not be what you want. An HTTP session is usually managed by storing a session ID in an HTTP cookie which is automatically sent by the browser along with each HTTP request, and at the server side this session ID is read and an associated, server side data structue is looked up by it.
A common solution is to use some kind of secret information referred to as a key or API key. The idea is that if you want to grant access to someone, you generate a secret key (e.g. a random text) at server side which you store in the database. You send this key to the client who has to attach this to every API request he makes. At server side in the beginning of each API request you can check if the provided API key is valid (this also identifies the caller) and act accordingly.
The API key can be sent in various ways by the clients, e.g. as a URL parameter (strongly not recommended for unsecure HTTP requests but is perfectly fine for HTTPS requests), as an HTTP header field or as part of the request data structure. It is really up to you how you expect it, usually depends on how the requests look like (e.g. if they don't include any data, it's better to put the KEY in a header or URL parameter; if the clients are expected to send other, complex data which can be in the form of JSON text, it can be convenient to also include the API key in the JSON data too).

httplib.HTTPConnection in Google AppEngine

I use httplib.HTTPConnection within my app. Do I really need to provide host parameter in httplib.HTTPConnection constructor? If so, why? (I mean, I know that it's a mandatory parameter, but I wonder if I could specify None or empty string) And is there any global constant in Google AppEngine and in development server which I can use within my app in order to omit explicitly defined host.
If you leave it out of the constructor, how will the other methods know where to send their messages?
The address/name of the server you're connecting to is the parameter for the HTTPConnection, the URI on that server is what goes into request.
From the python documentation (which is the basis for AppEngine)
h1 = httplib.HTTPConnection(host[, port[, strict[, timeout[, source_address]]]])
h1.request(method, url[, body[, headers]])
[edit]
Remember, it may not always be you who is responsible for this code. Also, why complicate things by including so much more information in the URI when you're (for example) making calls to numerous URI's on the same website?
[/edit]

Resources