Tellier Benoit commented on JAMES-1932:

Hi Shravan,

I believe the first step might be to have a front-end for editing configuration 
for the mailet container. You can see this configuration serialised as XML in 
mailetcontainer.xml. You can have a look at the CamelCompositeProcessor to see 
how this documentation is read.

Step number 2 is to allow to save this configuration and overwrite 
mailetcontainer.xml (maybe with renaming old configuration first).

Step number 3 might be to launch a CamelCompositeProcessor (a new one) from the 
web-based editor. We can imagine having some kind of Listener in it to keep 
track of the execution results (With registering special listeners ?). We can 
imagine feed it with "user uploaded emails". This would allow debugging.

Step number 4 might be to allow replacing the current CamelCompositeProcessor 
with the one from the editor, allowing live changes to the mailet pipeline, 
without restarting the server.

I believe the web-admin code should get control on this (the user 
edit/saves/replaces code). We might however need to be able to load current 
configuration in the web-editor. I would also value a clear separation of code 
with /server/mailet/mailetcontainer-camel ,  and to try to add these cool new 
features using composition. I also believe we need to track e-mail path for 
"under edition/debugging" mail pipeline, not the production one. I think this 
feature should not be "invasive" for production code.



> Mailet pipeline ui edition tool
> -------------------------------
>                 Key: JAMES-1932
>                 URL: https://issues.apache.org/jira/browse/JAMES-1932
>             Project: James Server
>          Issue Type: Task
>            Reporter: Matthieu Baechler
>              Labels: backend, frontend, gsoc2017, java, js, json, rest, sse
> James has to concept of mailet pipeline : for any incoming email, the email 
> is passing through the pipeline the is made of matchers and mailets. These 
> components allow to implement business rules based on some xml configuration 
> and some java component.
> That's a great strength of James and a lot of people use it for this 
> capability.
> Nevertheless, editing the pipeline and making tests is painful right now, you 
> are left finding solutions like "edit xml, launch server, send an email, read 
> logs".
> To ease adoption, we would like to make that process easy and fun by :
> * providing a web ui frontend to design the pipeline
> * given a set of emails, make it possible to visualise each email flow into 
> the mailet pipeline to test it
> * define a way to express the expected results to make sure people can save 
> their work into automated tests
> To implement that, the student must know enough about web frontend dev to 
> implement a pipeline designer and debugger.
> She or he will need to know some java to implement server side logic for :
> * make james accept to reconfigure its pipeline at runtime to take 
> modifications into account
> * design a protocol to stream debug data from a pipeline to the web ui and 
> implement it server-side in java
> * implement a junit runner to be able to run some special mailet tests based 
> on the work done in the web designer.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to