[jira] [Commented] (JAMES-3436) Saving Draft: convenience header & empty body
[
https://issues.apache.org/jira/browse/JAMES-3436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219566#comment-17219566
]
Benoit Tellier commented on JAMES-3436:
---
https://github.com/linagora/james-project/pull/3943 contributes the skeleton
for this (mailboxIds & subject field, delegation handling, mailbox not found
handling, clientId registration handling and syntax errors handling).
Other properties can be added on top of that work.
> Saving Draft: convenience header & empty body
> -
>
> Key: JAMES-3436
> URL: https://issues.apache.org/jira/browse/JAMES-3436
> Project: James Server
> Issue Type: Sub-task
> Components: JMAP
>Affects Versions: master
>Reporter: Benoit Tellier
>Assignee: Antoine Duprat
>Priority: Major
> Fix For: master
>
>
> = Why
> As a user, I want to create a mail draft (but empty body for the moment)
> = How
> Implement [`Email/set create` ](https://jmap.io/spec-mail.html#emailset)
> {code:java}
> [[ "Email/set", {
> "accountId": "ue150411c",
> "create": {
> "k192": {
> "mailboxIds": {
> "2ea1ca41b38e": true
> },
> "keywords": {
> "$seen": true,
> "$draft": true
> },
> "from": [{
> "name": "Joe Bloggs",
> "email": "j...@example.com"
> }],
> "subject": "World domination",
> "receivedAt": **"2018-07-10T01:03:11Z",
> "sentAt": "2018-07-10T11:03:11+10:00",
> }
> }
> }, "0" ]]
> {code}
> Notes:
> * omitting the body part for now (see #3910)
> * not all headers are allowed for now, only the convenience ones, as:
> * `references` | defaults to null
> * `inReplyTo` | defaults to null
> * `sender` | default to `from`
> * `from` | defaults to null
> * `to` | defaults to null
> * `cc` | defaults to null
> * `bcc` | defaults to null
> * `replyTo` | defaults to `to`
> * `subject` | defaults to null
> * `sentAt` | defaults to `now`
> * other parameters can set:
> * `mailboxIds` must be set
> * `keywords` | default is null
> * `receivedAt` | default is time of creation on server
> * server-set parameters:
> * `id`
> * `threadId`
> * `size`
> Restrictions:
> * The headers property MUST NOT be given on either the top-level Email or an
> EmailBodyPart — the client must set each header field as an individual
> property.
> * There MUST NOT be two properties that represent the same header field
> (e.g., header:from and from) within the Email or particular EmailBodyPart.
> * Header fields MUST NOT be specified in parsed forms that are forbidden for
> that particular field.
> * Header fields beginning with Content- MUST NOT be specified on the Email
> object, only on EmailBodyPart objects.
> = Definition of Done
> Write integration tests about email creation and error handlings.
> Delegation needs to be handled.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-3436) Saving Draft: convenience header & empty body
Benoit Tellier created JAMES-3436:
-
Summary: Saving Draft: convenience header & empty body
Key: JAMES-3436
URL: https://issues.apache.org/jira/browse/JAMES-3436
Project: James Server
Issue Type: Sub-task
Components: JMAP
Affects Versions: master
Reporter: Benoit Tellier
Assignee: Antoine Duprat
Fix For: master
= Why
As a user, I want to create a mail draft (but empty body for the moment)
= How
Implement [`Email/set create` ](https://jmap.io/spec-mail.html#emailset)
{code:java}
[[ "Email/set", {
"accountId": "ue150411c",
"create": {
"k192": {
"mailboxIds": {
"2ea1ca41b38e": true
},
"keywords": {
"$seen": true,
"$draft": true
},
"from": [{
"name": "Joe Bloggs",
"email": "j...@example.com"
}],
"subject": "World domination",
"receivedAt": **"2018-07-10T01:03:11Z",
"sentAt": "2018-07-10T11:03:11+10:00",
}
}
}, "0" ]]
{code}
Notes:
* omitting the body part for now (see #3910)
* not all headers are allowed for now, only the convenience ones, as:
* `references` | defaults to null
* `inReplyTo` | defaults to null
* `sender` | default to `from`
* `from` | defaults to null
* `to` | defaults to null
* `cc` | defaults to null
* `bcc` | defaults to null
* `replyTo` | defaults to `to`
* `subject` | defaults to null
* `sentAt` | defaults to `now`
* other parameters can set:
* `mailboxIds` must be set
* `keywords` | default is null
* `receivedAt` | default is time of creation on server
* server-set parameters:
* `id`
* `threadId`
* `size`
Restrictions:
* The headers property MUST NOT be given on either the top-level Email or an
EmailBodyPart — the client must set each header field as an individual property.
* There MUST NOT be two properties that represent the same header field (e.g.,
header:from and from) within the Email or particular EmailBodyPart.
* Header fields MUST NOT be specified in parsed forms that are forbidden for
that particular field.
* Header fields beginning with Content- MUST NOT be specified on the Email
object, only on EmailBodyPart objects.
= Definition of Done
Write integration tests about email creation and error handlings.
Delegation needs to be handled.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3432) Upload: Attachment
[
https://issues.apache.org/jira/browse/JAMES-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219549#comment-17219549
]
Nguyễn Việt Đức commented on JAMES-3432:
Upload size limitation is not done yet and it needs to be contribute
> Upload: Attachment
> --
>
> Key: JAMES-3432
> URL: https://issues.apache.org/jira/browse/JAMES-3432
> Project: James Server
> Issue Type: Sub-task
>Reporter: Nguyễn Việt Đức
>Priority: Major
>
> *Why*?
> User want to upload file/files for an account.
> How?
> *Request*
> To upload a file, the client submits an authenticated POST request to the
> file upload resource - which MUST contain a variable called accountId.
> Sample: "https://jmap.example.com/upload/\{accountId};
> *Response*
> A successful request MUST return a single JSON object with the following
> properties as the response:
> {code:java}
> *accountId*: Id The id of the account used for the call.
> *blobId*: Id The id representing the binary data uploaded. The data for this
> id is immutable. The id only refers to the binary data, not any metadata.
> *type*: String The media type of the file (as specified in [@!RFC6838],
> Section 4.2) as set in the Content-Type header of the upload HTTP request.
> *size*: UnsignedInt The size of the file in octets.
> {code}
> *Note*
> If identical binary content to an existing blob in the account is uploaded,
> the existing blobId MAY be returned.
> Clients should use the blobId returned in a timely manner. Under rare
> circumstances, the server may have deleted the blob before the client uses
> it; the client should keep a reference to the local file so it can upload it
> again in such a situation.
> When an HTTP error response is returned to the client, the server SHOULD
> return a JSON “problem details” object as the response body, as per
> [@!RFC7807].
> As access controls are often determined by the object holding the reference
> to a blob, unreferenced blobs MUST only be accessible to the uploader, even
> in shared accounts.
> *Definition of done*
> {code:java}
> When bob uploads an attachment
> Then an upload response is sent to him
> And using the blobId specified in the upload response, bob can download that
> attachment
> {code}
> Write integration tests for it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3435) Relaxing LWT usage: domain, users
[
https://issues.apache.org/jira/browse/JAMES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219546#comment-17219546
]
ASF GitHub Bot commented on JAMES-3435:
---
chibenwa commented on pull request #255:
URL: https://github.com/apache/james-project/pull/255#issuecomment-715151761
> Managing domain and users is not a very recurring operation
Reading them is.
And SERIAL consistency is required in such cases, implying a read of paxos
system table.
That's why I do you expect some performance improvement by relaxing these
constraints.
That being said, it looks like SERIAL consistency level was not even
specified there (!!!) giving a false feeling of safety (we likely had untested
concurrency issues with this validation behavior).
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Relaxing LWT usage: domain, users
> -
>
> Key: JAMES-3435
> URL: https://issues.apache.org/jira/browse/JAMES-3435
> Project: James Server
> Issue Type: Improvement
> Components: cassandra
>Affects Versions: master
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: master
>
>
> https://www.mail-archive.com/server-dev@james.apache.org/msg68713.html
> {code:java}
> Cassandra is an eventually consistent datastore, that can be used in a
> consistant fashion. To do so, we rely on a mechanism called "LightWeight
> Transactions (LWT)". Lightweight transactions relies on the PAXOS
> distributed consensus algorithm to enforce a condition upon data
> mutation. A table, system.paxos, is used to track the state of
> transactions. Furthermore, upon writes, several round-trips (two) are
> needed to ensure data integrity accross replica(minimum round trips to
> achieve consensus) and the system.paxos table is read / written to in
> addition to the applicative table.
> All of this causes LWT to be significantly slower than their lower
> consistency counterparts. On some Linagora owned production instances,
> regular reads takes 2ms while reads on tables relying on LWT takes 6ms.
> Similar figures are found for writes. We also noticed some high
> compaction throughtput on the paxos table, leading to many back-ground
> writes.
> Given the massive impact of LWT usage on performance, and given the lack
> of debate upon LWT adoption, I would like to re-challenge their usage...
> Here are the places we rely on LWT for the Distributed Server:
> - IMAP UID generation (monotic integer) - strong consistency is
> strictly required to not loose data as overwriting a uid means
> overwriting a message.
> - IMAP ModSeq generation (monotic integer) - strong consistency is
> required, as modseq overwrites can lead to some data not being well
> synchronised.
> - Domain and users - we rely on LWT to return an error when deleting a
> user that do not exist, or creating an already existing user. It sounds
> unecessary.
> - Message flags relies on LWT to ensure updates are not overwritten. As
> an often read metadata, the impact is high, for limited criticity for
> the end user. After all, no data is lost, only a user action like
> marking a message as Seen, an action that he can very well perform again
> - Mailbox path registration, ACL - required to prevent data races
> My proposal would be:
> - Keep using LWT for UID and modseq generation, as well as Mailbox path
> registration.
> - Make the use of LWT for message flags update configurable - as an
> admin I can choose to disable it.
> - I am also fine with completly removing LWT usage for message flags
> update.
> - No longer use LWT on domain or users. Instead use idempotent create /
> delete. The contract test will thus need to be relaxed.
> - On the long term, relying on a CRDT to represent ACLs at the
> Cassandra level, instead of serialized JSON, would enable to get rid of
> LWT usage on the ACL table.
> {code}
> Let's start relaxing LWT transaction for users & domains.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3389) New API endpoint to accept incoming message
[
https://issues.apache.org/jira/browse/JAMES-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219544#comment-17219544
]
ASF GitHub Bot commented on JAMES-3389:
---
chibenwa commented on a change in pull request #256:
URL: https://github.com/apache/james-project/pull/256#discussion_r510707090
##
File path:
server/protocols/webadmin/webadmin-mail-over-web/src/test/resources/json/mail.json
##
@@ -0,0 +1,13 @@
+{
Review comment:
> After that i will try to implement the request payload as the
emailSubmission object.
Don't. I did share them in order to highlight that this is a complex topic.
I would personnally prefer passing the mail envelope via URL query
parameters, and having the request payload being the raw MIME message. (I think
having the raw MIME EML submission format is really easy to use). The client
system could be as simple as a curl command (good inter-operability, but client
system have to generate mime messages itself).
If we want to support another format, JSON based, we could use the Accept
header to specify the Mail to be sent, and could be friendlier to modern
application (but we won't have a one format fit all use cases without some
over-engineering - we should rather start with something simple). The client
system would need to be adapted to this format (limited inter-operability).
In short `message/rfc822` => raw EML as a request body, envelope parameters
in the URL - and `application/json` a JSON format, if we want to.
I propose you write an API proposition, with examples, in the JIRA ticket
before implementing more things.
(You can of course take care of stylish and location issues).
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> New API endpoint to accept incoming message
> ---
>
> Key: JAMES-3389
> URL: https://issues.apache.org/jira/browse/JAMES-3389
> Project: James Server
> Issue Type: Improvement
>Reporter: Juhan Aasaru
>Priority: Major
>
> We have messages arriving over a web service (not SMPT). For this we need a
> new API endpoint that would accept the message and insert it into the queue
> (ActiveMQ / rabbitMQ) for the email to be processed and stored.
> This new code would be placed to webadmin where all of the REST API-s live.
> Since the underlying queues are a bit different (ActiveMQ vs RabbitMQ) it
> needs to be designed in a way that it works for all configurations.
> Original discussion:
> [https://www.mail-archive.com/server-user@james.apache.org/msg16399.html]
> I would like to work on this myself but it will take me some weeks before I
> can start. Feel free to discuss under this task how to design it best. All
> the ideas how to solve this technically are taken from the thread in the
> mailing list - I haven't looked at the code myself yet.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3389) New API endpoint to accept incoming message
[
https://issues.apache.org/jira/browse/JAMES-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219543#comment-17219543
]
ASF GitHub Bot commented on JAMES-3389:
---
chibenwa commented on a change in pull request #256:
URL: https://github.com/apache/james-project/pull/256#discussion_r510707090
##
File path:
server/protocols/webadmin/webadmin-mail-over-web/src/test/resources/json/mail.json
##
@@ -0,0 +1,13 @@
+{
Review comment:
> After that i will try to implement the request payload as the
emailSubmission object.
Don't. I points it to show you this is a complex topic.
I would prefer passing the mail envelope via URL query parameters, and
having the request payload being the raw MIME message. (I think having the raw
MIME EML submission format is really easy to use). The client system could be
as simple as a curl command (good inter-operability, but client system have to
generate mime messages itself).
If we want to support another format, JSON based, we could use the Accept
header to specify the Mail to be sent, and could be friendlier to modern
application (but we won't have a one format fit all use cases without some
over-engineering - we should rather start with something simple). The client
system would need to be adapted to this format (limited inter-operability).
I propose you write an API proposition, with examples, in the JIRA ticket
before implementing more things.
(You can of course take care of stylish and location issues).
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> New API endpoint to accept incoming message
> ---
>
> Key: JAMES-3389
> URL: https://issues.apache.org/jira/browse/JAMES-3389
> Project: James Server
> Issue Type: Improvement
>Reporter: Juhan Aasaru
>Priority: Major
>
> We have messages arriving over a web service (not SMPT). For this we need a
> new API endpoint that would accept the message and insert it into the queue
> (ActiveMQ / rabbitMQ) for the email to be processed and stored.
> This new code would be placed to webadmin where all of the REST API-s live.
> Since the underlying queues are a bit different (ActiveMQ vs RabbitMQ) it
> needs to be designed in a way that it works for all configurations.
> Original discussion:
> [https://www.mail-archive.com/server-user@james.apache.org/msg16399.html]
> I would like to work on this myself but it will take me some weeks before I
> can start. Feel free to discuss under this task how to design it best. All
> the ideas how to solve this technically are taken from the thread in the
> mailing list - I haven't looked at the code myself yet.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3435) Relaxing LWT usage: domain, users
[
https://issues.apache.org/jira/browse/JAMES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219537#comment-17219537
]
ASF GitHub Bot commented on JAMES-3435:
---
rouazana commented on pull request #255:
URL: https://github.com/apache/james-project/pull/255#issuecomment-715125452
I'm not sure to get the value of this change. Managing domain and users is
not a very recurring operation, so why do you expect some performance
improvement by relaxing these constraints?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Relaxing LWT usage: domain, users
> -
>
> Key: JAMES-3435
> URL: https://issues.apache.org/jira/browse/JAMES-3435
> Project: James Server
> Issue Type: Improvement
> Components: cassandra
>Affects Versions: master
>Reporter: Benoit Tellier
>Priority: Major
> Fix For: master
>
>
> https://www.mail-archive.com/server-dev@james.apache.org/msg68713.html
> {code:java}
> Cassandra is an eventually consistent datastore, that can be used in a
> consistant fashion. To do so, we rely on a mechanism called "LightWeight
> Transactions (LWT)". Lightweight transactions relies on the PAXOS
> distributed consensus algorithm to enforce a condition upon data
> mutation. A table, system.paxos, is used to track the state of
> transactions. Furthermore, upon writes, several round-trips (two) are
> needed to ensure data integrity accross replica(minimum round trips to
> achieve consensus) and the system.paxos table is read / written to in
> addition to the applicative table.
> All of this causes LWT to be significantly slower than their lower
> consistency counterparts. On some Linagora owned production instances,
> regular reads takes 2ms while reads on tables relying on LWT takes 6ms.
> Similar figures are found for writes. We also noticed some high
> compaction throughtput on the paxos table, leading to many back-ground
> writes.
> Given the massive impact of LWT usage on performance, and given the lack
> of debate upon LWT adoption, I would like to re-challenge their usage...
> Here are the places we rely on LWT for the Distributed Server:
> - IMAP UID generation (monotic integer) - strong consistency is
> strictly required to not loose data as overwriting a uid means
> overwriting a message.
> - IMAP ModSeq generation (monotic integer) - strong consistency is
> required, as modseq overwrites can lead to some data not being well
> synchronised.
> - Domain and users - we rely on LWT to return an error when deleting a
> user that do not exist, or creating an already existing user. It sounds
> unecessary.
> - Message flags relies on LWT to ensure updates are not overwritten. As
> an often read metadata, the impact is high, for limited criticity for
> the end user. After all, no data is lost, only a user action like
> marking a message as Seen, an action that he can very well perform again
> - Mailbox path registration, ACL - required to prevent data races
> My proposal would be:
> - Keep using LWT for UID and modseq generation, as well as Mailbox path
> registration.
> - Make the use of LWT for message flags update configurable - as an
> admin I can choose to disable it.
> - I am also fine with completly removing LWT usage for message flags
> update.
> - No longer use LWT on domain or users. Instead use idempotent create /
> delete. The contract test will thus need to be relaxed.
> - On the long term, relying on a CRDT to represent ACLs at the
> Cassandra level, instead of serialized JSON, would enable to get rid of
> LWT usage on the ACL table.
> {code}
> Let's start relaxing LWT transaction for users & domains.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3389) New API endpoint to accept incoming message
[
https://issues.apache.org/jira/browse/JAMES-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219518#comment-17219518
]
ASF GitHub Bot commented on JAMES-3389:
---
andrevka commented on a change in pull request #256:
URL: https://github.com/apache/james-project/pull/256#discussion_r510685206
##
File path:
server/protocols/webadmin/webadmin-mail-over-web/src/test/resources/json/mail.json
##
@@ -0,0 +1,13 @@
+{
Review comment:
Thanks for the pointers. I'll start with fixing the coding style issues
right away, and moving the code to the mailqueue module. After that i will try
to implement the request payload as the emailSubmission object.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> New API endpoint to accept incoming message
> ---
>
> Key: JAMES-3389
> URL: https://issues.apache.org/jira/browse/JAMES-3389
> Project: James Server
> Issue Type: Improvement
>Reporter: Juhan Aasaru
>Priority: Major
>
> We have messages arriving over a web service (not SMPT). For this we need a
> new API endpoint that would accept the message and insert it into the queue
> (ActiveMQ / rabbitMQ) for the email to be processed and stored.
> This new code would be placed to webadmin where all of the REST API-s live.
> Since the underlying queues are a bit different (ActiveMQ vs RabbitMQ) it
> needs to be designed in a way that it works for all configurations.
> Original discussion:
> [https://www.mail-archive.com/server-user@james.apache.org/msg16399.html]
> I would like to work on this myself but it will take me some weeks before I
> can start. Feel free to discuss under this task how to design it best. All
> the ideas how to solve this technically are taken from the thread in the
> mailing list - I haven't looked at the code myself yet.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3398) Add maven wrapper to the project
[ https://issues.apache.org/jira/browse/JAMES-3398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219504#comment-17219504 ] ASF GitHub Bot commented on JAMES-3398: --- chibenwa commented on a change in pull request #253: URL: https://github.com/apache/james-project/pull/253#discussion_r510669086 ## File path: .mvn/wrapper/MavenWrapperDownloader.java ## @@ -0,0 +1,117 @@ +/* + * Copyright 2007-present the original author or authors. + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +import java.net.*; +import java.io.*; +import java.nio.channels.*; +import java.util.Properties; + Review comment: I understand this code is copied but can we have a link to the place it was copied from as a comment? This helps code patternity. This helps checking divergences from the original version. ## File path: mvnw.cmd ## @@ -0,0 +1,182 @@ +@REM +@REM Licensed to the Apache Software Foundation (ASF) under one +@REM or more contributor license agreements. See the NOTICE file +@REM distributed with this work for additional information +@REM regarding copyright ownership. The ASF licenses this file +@REM to you under the Apache License, Version 2.0 (the +@REM "License"); you may not use this file except in compliance +@REM with the License. You may obtain a copy of the License at +@REM +@REMhttp://www.apache.org/licenses/LICENSE-2.0 +@REM +@REM Unless required by applicable law or agreed to in writing, +@REM software distributed under the License is distributed on an +@REM "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +@REM KIND, either express or implied. See the License for the +@REM specific language governing permissions and limitations +@REM under the License. +@REM + Review comment: URL? ## File path: mvnw ## @@ -0,0 +1,310 @@ +#!/bin/sh +# +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +#http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +# + Review comment: Idem, I would welcome a URL from where this was copied. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add maven wrapper to the project > > > Key: JAMES-3398 > URL: https://issues.apache.org/jira/browse/JAMES-3398 > Project: James Server > Issue Type: Improvement >Reporter: Juhan Aasaru >Priority: Major > > This way everyone has the same maven version to build the project and thus > there are less problems that can be caused by different setups > More info: [https://github.com/takari/maven-wrapper] > > I would like to work on this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3389) New API endpoint to accept incoming message
[
https://issues.apache.org/jira/browse/JAMES-3389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219500#comment-17219500
]
ASF GitHub Bot commented on JAMES-3389:
---
chibenwa commented on a change in pull request #256:
URL: https://github.com/apache/james-project/pull/256#discussion_r510659597
##
File path:
server/container/guice/protocols/webadmin-mail-over-web/src/main/java/org/apache/james/modules/server/WebAdminMailOverWebModule.java
##
@@ -0,0 +1,16 @@
+package org.apache.james.modules.server;
Review comment:
The Apache V2 license header is compulsory.
##
File path:
server/protocols/webadmin/webadmin-mail-over-web/src/main/java/org/apache/james/webadmin/routes/ReceiveMailOverWebRoutes.java
##
@@ -0,0 +1,86 @@
+package org.apache.james.webadmin.routes;
+
+import javax.inject.Inject;
+import javax.ws.rs.POST;
+import javax.ws.rs.Path;
+import javax.ws.rs.Produces;
+
+import org.apache.james.queue.api.MailQueue;
+import org.apache.james.queue.api.MailQueueFactory;
+import org.apache.james.server.core.MailImpl;
+import org.apache.james.webadmin.Routes;
+import org.apache.james.webadmin.request.MailProps;
+import org.apache.james.webadmin.utils.ErrorResponder;
+import org.apache.james.webadmin.utils.JsonExtractor;
+import org.eclipse.jetty.http.HttpStatus;
+
+import io.swagger.annotations.Api;
+import io.swagger.annotations.ApiImplicitParam;
+import io.swagger.annotations.ApiImplicitParams;
+import io.swagger.annotations.ApiOperation;
+import io.swagger.annotations.ApiResponse;
+import io.swagger.annotations.ApiResponses;
+import spark.Service;
+
+@Api(tags = "OverWebMailReceiver")
+@Path(ReceiveMailOverWebRoutes.BASE_URL)
+@Produces("application/json")
+public class ReceiveMailOverWebRoutes implements Routes {
+
+private final JsonExtractor mailPropsJsonExtractor;
+
+public static final String BASE_URL = "/receiveMail";
+
+private MailQueue queue;
+
+@Override
+public String getBasePath() {
+return BASE_URL;
+}
+
+@Inject
+public ReceiveMailOverWebRoutes(MailQueueFactory queueFactory) {
+queue = queueFactory.createQueue(MailQueueFactory.SPOOL);
+this.mailPropsJsonExtractor = new JsonExtractor<>(MailProps.class);
+}
+
+@Override
+public void define(Service service) {
+defineReceiveMailFromWebService(service);
+}
+
+@POST
+@Path("/receiveMail")
+@ApiOperation(value = "Deleting an user")
+@ApiImplicitParams({
+@ApiImplicitParam(required = true, dataType = "string", name =
"username", paramType = "path")
+})
+@ApiResponses(value = {
+@ApiResponse(code = HttpStatus.NO_CONTENT_204, message = "OK. User
is removed."),
+@ApiResponse(code = HttpStatus.BAD_REQUEST_400, message = "Invalid
input user."),
+@ApiResponse(code = HttpStatus.INTERNAL_SERVER_ERROR_500,
+message = "Internal server error - Something went bad on
the server side.")
+})
+public void defineReceiveMailFromWebService(Service service) {
+service.post(BASE_URL, (request, response) -> {
+try {
+//Parse the json object to
org.apache.james.webadmin.request.MailProps and build the MailImpl object
+MailImpl mail =
mailPropsJsonExtractor.parse(request.body()).asMailImpl();
+//Send to queue api for mail processing
+queue.enQueue(mail);
+response.body("ENQUEUED");
+response.status(204);
+} catch (Exception e) {
+ErrorResponder.builder()
+.cause(e)
+.statusCode(500)
+.type(ErrorResponder.ErrorType.SERVER_ERROR)
+.message("The mail will not be sent: " +
e.getMessage())
+.haltError();
Review comment:
We have default error handling, this is not required to handle it
manually here
##
File path: server/container/guice/pom.xml
##
@@ -73,6 +73,7 @@
protocols/webadmin-mailrepository
protocols/webadmin-rabbitmq-mailqueue
protocols/webadmin-swagger
+protocols/webadmin-mail-over-web
Review comment:
I propose to not add yet-another module but add it to
`protocols/webadmin-mailqueue`
##
File path:
server/protocols/webadmin/webadmin-mail-over-web/src/main/java/org/apache/james/webadmin/request/BodyPartProps.java
##
@@ -0,0 +1,89 @@
+package org.apache.james.webadmin.request;
+
+import java.util.HashMap;
+import java.util.Map;
+import java.util.Optional;
+
+import com.fasterxml.jackson.annotation.JsonCreator;
+import com.fasterxml.jackson.annotation.JsonProperty;
+
+public class BodyPartProps {
+
+@JsonCreator
+public BodyPartProps(
+@JsonProperty("type") String type,
+@JsonProperty("filename")
