[jira] [Commented] (JAMES-1449) Mege App project back in James Server
[ https://issues.apache.org/jira/browse/JAMES-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13540585#comment-13540585 ] Stefano Bagnara commented on JAMES-1449: +1 > Mege App project back in James Server > - > > Key: JAMES-1449 > URL: https://issues.apache.org/jira/browse/JAMES-1449 > Project: James Server > Issue Type: Task > Components: Build System >Affects Versions: Trunk >Reporter: Ioan Eugen Stan >Assignee: Ioan Eugen Stan > Fix For: Trunk > > > Merge James App back in James server and remove James App -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JDKIM-2) Add logging with commons logging
[ https://issues.apache.org/jira/browse/JDKIM-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13539738#comment-13539738 ] Stefano Bagnara commented on JDKIM-2: - About logging frameworks I still think the same things I wrote in the one year old thread Eric linked in his comment. "slf4j instead of commons-logging since the later creates issues with class-loaders in general and OSGi in particular.": IMHO this is a myth nowadays, anyway I mostly used commons-logging by injecting the logger instances in the classes so the classloader didn't apply at all. That said, jDKIM is a very slim library and using it I found it is stable and I never needed logging at all. Since opening this issue I guess I removed the System.out calls and improved some exceptions. Unless some user ask for some specific thing to be logged I think we should simply close this issue as won't fix. I found myself using the Observer pattern almost everywhere instead of a logging framework when writing libraries. This way you don't introduce a new dependency and you give much more power to the library users. I said "Observer pattern" but in fact I use something simpler, without the need to keep a listener registry. Simply create an eventlistener interface including meaningful methods for your domain and then let your classes "receive" implementations for this listener in their constructor or exposing a setter, then invoke it with if (listener != null) listener.itJustHappened(). > Add logging with commons logging > > > Key: JDKIM-2 > URL: https://issues.apache.org/jira/browse/JDKIM-2 > Project: James jDKIM > Issue Type: Improvement > Components: library >Affects Versions: 0.2 >Reporter: Stefano Bagnara >Assignee: Stefano Bagnara > Fix For: 1.0 > > > Currently there are some System.out and exception based logging. Maybe real > logging is better at least for some component. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1427) DoS scenario(s) in SMTP server
[ https://issues.apache.org/jira/browse/JAMES-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13420677#comment-13420677 ] Stefano Bagnara commented on JAMES-1427: +1 for A and B I don't like too much C because this way the client is not "aware" of the real error and is going to get it as a temporary network error and retry. Instead if you let it send the whole file and at the end you give it a permanent error it will stop trying. So it is better to receive and /dev/null 100MB once than receive 10 MB and disconnect for a dozen attempts in 5 days. > DoS scenario(s) in SMTP server > -- > > Key: JAMES-1427 > URL: https://issues.apache.org/jira/browse/JAMES-1427 > Project: JAMES Server > Issue Type: Bug > Components: SMTPServer >Affects Versions: 3.0-beta3 >Reporter: Andrzej Rusin > > 1. SMTP server allows unlimited number of invalid commands, which may waste > network bandwidth. > 2. The invalid commands go straight to the logs with level INFO, which can > easily fill up the server disk. > Additionally: > 3. After the max message size is reached, the SMTP server denies the message, > but client keeps sending, which makes the remaining part of the message go > straight to the log because of 2. > Ideas to fix: > A. Do not log more than N invalid commands per connection - solve 2, > B. Drop connection after Nth (consecutive?) invalid command - solve 1 and 2, > C. (This one is questionable) Drop the connection after max message size is > reached - solve 3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JDKIM-30) Submit the library to dkim.org
Submit the library to dkim.org -- Key: JDKIM-30 URL: https://issues.apache.org/jira/browse/JDKIM-30 Project: JAMES jDKIM Issue Type: Task Reporter: Stefano Bagnara Priority: Minor jDKIM is not listed in http://www.dkim.org/deploy/index.html Here is the submit page: http://www.dkim.org/deploy/report-template.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1260) Download from mirrors is broken
[
https://issues.apache.org/jira/browse/JAMES-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081070#comment-13081070
]
Stefano Bagnara commented on JAMES-1260:
I just updated site.vm because downloadTracking was broken (it used the old
urchin script way to do that and somehow now we moved to the async tracking
code).
I also reverted item(X) to [ X ] (using spaces) because my chrome was throwing
syntax errors on the item() call for simple arrays (not on the dom elements
resultsets).
> Download from mirrors is broken
> ---
>
> Key: JAMES-1260
> URL: https://issues.apache.org/jira/browse/JAMES-1260
> Project: JAMES Server
> Issue Type: Bug
>Reporter: Eric Charles
>Assignee: Felix Knecht
> Fix For: Trunk
>
>
> Further to last project website deploy, error [1] arised.
> It seems that [2] was forseen to avoid the problem, but block [3] rises [2].
> For now, line [4] has been removed.
> [1]
> Problem running mirror.cgi, contact if it
> persists.
> Traceback (most recent call last):
> File "/www/www.apache.org/dyn/mirrors/mirrors.cgi", line 124, in mirrorwrap
> return mirrorsapp(environ, start_response)
> File "/www/www.apache.org/dyn/mirrors/mirrors.cgi", line 200, in mirrorsapp
> template.generate(output, data)
> File "/x1/www/www.apache.org/content/dyn/mirrors/ezt.py", line 320, in
> generate
> self._execute(self.program, fp, ctx)
> File "/x1/www/www.apache.org/content/dyn/mirrors/ezt.py", line 480, in
> _execute
> method(method_args, fp, ctx, filename, line_number)
> File "/x1/www/www.apache.org/content/dyn/mirrors/ezt.py", line 483, in
> _cmd_print
> value = _get_value(valref, ctx, filename, line_number)
> File "/x1/www/www.apache.org/content/dyn/mirrors/ezt.py", line 665, in
> _get_value
> raise UnknownReference(refname, filename, line_number)
> UnknownReference: 0 in file /x1/www/james.apache.org/download.html at line 35
> [2]--
> The mirror choosing script replaces any simple word in square bracket and was
> breaking the new javascript.
> Added a "0+" in front of each index in square bracket.
> https://svn.apache.org/viewvc/james/project/trunk/maven-skin/src/main/resources/META-INF/maven/site.vm?revision=532445&view=markup
>
> [3]
> (function() {
> var ga = document.createElement('script'); ga.type = 'text/javascript';
> ga.async = true;
> ga.src = ('https:' == document.location.protocol ? 'https://ssl' :
> 'http://www') + '.google-analytics.com/ga.js';
> -> Issue arises here [4]: var s =
> document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
> })();
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JDKIM-27) Put James JDKIM into Maven
[ https://issues.apache.org/jira/browse/JDKIM-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara resolved JDKIM-27. -- Resolution: Fixed Assignee: Stefano Bagnara Not solved yet, but we prepared for it to be solved. It will be solved once we release 0.2. > Put James JDKIM into Maven > -- > > Key: JDKIM-27 > URL: https://issues.apache.org/jira/browse/JDKIM-27 > Project: JAMES jDKIM > Issue Type: New Feature > Components: library, mailet >Affects Versions: 0.2 >Reporter: Al Briggs >Assignee: Stefano Bagnara > Labels: build, maven > Fix For: 0.2 > > Original Estimate: 24h > Remaining Estimate: 24h > > It seems the project has not been active since 2009 - but as the library is > still useful it would be much better to have it in Maven so that it can be > more easily used. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JDKIM-27) Put James JDKIM into Maven
[ https://issues.apache.org/jira/browse/JDKIM-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13070441#comment-13070441 ] Stefano Bagnara commented on JDKIM-27: -- The project is active but no issues have been reported so no improvements have been done to the project. We didn't release earlier mainly because this required a non released mime4j version. Now mime4j 0.7 has been released and we're going to make an official release for jdkim too. I know at least 3 big mail senders (sending millions mail per day) that deployed jdkim in production succesfully (2 in james server as mailets, 1 using only the main library in a custom mail server). I close this because this will get solved as soon as we release 0.2 (our release process include publishing to maven repository now). > Put James JDKIM into Maven > -- > > Key: JDKIM-27 > URL: https://issues.apache.org/jira/browse/JDKIM-27 > Project: JAMES jDKIM > Issue Type: New Feature > Components: library, mailet >Affects Versions: 0.2 >Reporter: Al Briggs > Labels: build, maven > Fix For: 0.2 > > Original Estimate: 24h > Remaining Estimate: 24h > > It seems the project has not been active since 2009 - but as the library is > still useful it would be much better to have it in Maven so that it can be > more easily used. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JDKIM-29) Prepare LICENSE/NOTICE stuff for releasing
[ https://issues.apache.org/jira/browse/JDKIM-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara resolved JDKIM-29. -- Resolution: Fixed Fix Version/s: 0.2 > Prepare LICENSE/NOTICE stuff for releasing > -- > > Key: JDKIM-29 > URL: https://issues.apache.org/jira/browse/JDKIM-29 > Project: JAMES jDKIM > Issue Type: Task >Reporter: Stefano Bagnara >Assignee: Stefano Bagnara >Priority: Blocker > Fix For: 0.2 > > > I just removed sun's javamail from dependencies. > We have to create a LICENSE/NOTICE for the binary file, make sure the binary > package includes all of our jars and update main LICENSE/NOTICE to only > reflect source tree licensing (not licensing for jars included only in the > binary distribution) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JDKIM-29) Prepare LICENSE/NOTICE stuff for releasing
Prepare LICENSE/NOTICE stuff for releasing -- Key: JDKIM-29 URL: https://issues.apache.org/jira/browse/JDKIM-29 Project: JAMES jDKIM Issue Type: Task Reporter: Stefano Bagnara Assignee: Stefano Bagnara Priority: Blocker I just removed sun's javamail from dependencies. We have to create a LICENSE/NOTICE for the binary file, make sure the binary package includes all of our jars and update main LICENSE/NOTICE to only reflect source tree licensing (not licensing for jars included only in the binary distribution) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1286) Factor Out Application Assembly
[ https://issues.apache.org/jira/browse/JAMES-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058028#comment-13058028 ] Stefano Bagnara commented on JAMES-1286: Sorry I just received the mailing list (jira get higher priorities in my inbox ;-) ) and I read all the thread. Reading all opinions I still think this is not a good idea. The licensing/notice review is taking time now because this is the first time we do this after an almost full codebase rewrite, I expect most time we'll need new releases for code issues (bugs) and not licensing, so this will take every time a double vote process in order to release a new beta or a new dot release and this doesn't sound good at all. I don't get how splitting the releases will make the review faster? (either way the number of jars/poms/tar.gz modules to be reviewed is the same (you just split the vote in 2, slowing the release process that is already a lot slower than past because of mailbox/imap/mailet-api and other dependencies we now have as separated projects). So I cast a -0 to this. > Factor Out Application Assembly > --- > > Key: JAMES-1286 > URL: https://issues.apache.org/jira/browse/JAMES-1286 > Project: JAMES Server > Issue Type: Task > Components: Build System >Affects Versions: 3.0-beta1 >Reporter: Robert Burrell Donkin >Assignee: Robert Burrell Donkin >Priority: Blocker > > Assembling the final james application from the server components from which > it is composed. Integrating these builds necessitates that application and > server components are released together. Until maintenance of license and > notice information can be automated, this creates a bottleneck and any > problem with either server components or application assembly stops both > releases. Application assembly is logical downstream of the server component > build. This bottleneck can be eliminated by releasing the server components > first and then the assembled application. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1286) Factor Out Application Assembly
[ https://issues.apache.org/jira/browse/JAMES-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058018#comment-13058018 ] Stefano Bagnara commented on JAMES-1286: Are you sure this will speed up our process? It sounds like it will take one more vote each time... Currently a server release without the assembled release is useless (no downstream users of the modules but the assembly itself), so I don't see improvements in the separation/double vote (maybe I missed the point of the issue?) > Factor Out Application Assembly > --- > > Key: JAMES-1286 > URL: https://issues.apache.org/jira/browse/JAMES-1286 > Project: JAMES Server > Issue Type: Task > Components: Build System >Affects Versions: 3.0-beta1 >Reporter: Robert Burrell Donkin >Assignee: Robert Burrell Donkin >Priority: Blocker > > Assembling the final james application from the server components from which > it is composed. Integrating these builds necessitates that application and > server components are released together. Until maintenance of license and > notice information can be automated, this creates a bottleneck and any > problem with either server components or application assembly stops both > releases. Application assembly is logical downstream of the server component > build. This bottleneck can be eliminated by releasing the server components > first and then the assembled application. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1282) API package in mailetcontainer-library should be moved to new module
[ https://issues.apache.org/jira/browse/JAMES-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057435#comment-13057435 ] Stefano Bagnara commented on JAMES-1282: Can't we simply remove the mailetcontainer.xml from the library module? BTW I still find the current structure better than what you propose, but this is just my opinion. You are on the code right now so I'm fine with your opinion to "win" against mine but I'll keep my opinion ;-) > API package in mailetcontainer-library should be moved to new module > - > > Key: JAMES-1282 > URL: https://issues.apache.org/jira/browse/JAMES-1282 > Project: JAMES Server > Issue Type: Task > Components: SpoolManager & Processors >Affects Versions: 3.0-M2 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta1 > > > To better seperate the implementation from the api its necessary to move the > API package out of mailetcontainer-library to its extra module -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1282) API package in mailetcontainer-library should be moved to new module
[ https://issues.apache.org/jira/browse/JAMES-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13057176#comment-13057176 ] Stefano Bagnara commented on JAMES-1282: Can you explain what's the problem with OSGi and our current module layout: maybe once I understand this I will also understand your motivations :-) > API package in mailetcontainer-library should be moved to new module > - > > Key: JAMES-1282 > URL: https://issues.apache.org/jira/browse/JAMES-1282 > Project: JAMES Server > Issue Type: Task > Components: SpoolManager & Processors >Affects Versions: 3.0-M2 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta1 > > > To better seperate the implementation from the api its necessary to move the > API package out of mailetcontainer-library to its extra module -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1282) API package in mailetcontainer-library should be moved to new module
[ https://issues.apache.org/jira/browse/JAMES-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13056609#comment-13056609 ] Stefano Bagnara commented on JAMES-1282: IMO a bunch of interfaces in a package named "api" doesn't make it a real API automatically. An api is much more than this (and IMO it doesn't even need interfaces or a package named api to be an api). That's why I think the previous solution (a single module) is still the best. I see no reasons to separate it into multiple modules so I would simply keep a single one. I looked at the code in that api package and I still think that it is not an api because I don't really understand why someone should program against that interfaces: we created that interfaces mainly because avalon worked that way (1 interface per service). That said I won't veto the change, I just wanted to speak loudly about a change I don't like as soon as I saw it (the fact that I spent my few development time to merge them few months ago explain how much I feel this :-) ). To change my mind I would have to see an alternative, (non camel based), implementation that still use some common code (I would write everything from scratch without reusing that "loader" stuff, simply because no other james module really care of that api, so it is really some small interface local to the spooler and doesn't create any cooperation/bridge/contract with the rest of james modules. So IMO that interfaces do not worth a module. > API package in mailetcontainer-library should be moved to new module > - > > Key: JAMES-1282 > URL: https://issues.apache.org/jira/browse/JAMES-1282 > Project: JAMES Server > Issue Type: Task > Components: SpoolManager & Processors >Affects Versions: 3.0-M2 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta1 > > > To better seperate the implementation from the api its necessary to move the > API package out of mailetcontainer-library to its extra module -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1282) API package in mailetcontainer-library should be moved to new module
[ https://issues.apache.org/jira/browse/JAMES-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13055755#comment-13055755 ] Stefano Bagnara commented on JAMES-1282: I don't agre on the OSGi side: they must be separate modules only if you have different modules depending on them or alternative implementations. AFAIK we are not in this cases, now. And I still think that "api" is not a good package name (and even worse module name) for that 3 interfaces + JMX stuff. I'll change my mind once I see an alternative implementation or some module depending on the api package and not on the remaining stuff (nothing changed since we agreed on the merge ;-) ). We shouldn't add new modules unless it's strictly necessary: we worked a lot to reduce their number. > API package in mailetcontainer-library should be moved to new module > - > > Key: JAMES-1282 > URL: https://issues.apache.org/jira/browse/JAMES-1282 > Project: JAMES Server > Issue Type: Task > Components: SpoolManager & Processors >Affects Versions: 3.0-M2 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta1 > > > To better seperate the implementation from the api its necessary to move the > API package out of mailetcontainer-library to its extra module -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1282) API package in mailetcontainer-library should be moved to new module
[ https://issues.apache.org/jira/browse/JAMES-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13055725#comment-13055725 ] Stefano Bagnara commented on JAMES-1282: I'm confused: we merged them 5 months ago in JAMES-1184 I don't think other containers will use *these* api. If we have api we think are common to containers then we should move them to the mailet api. And probably "api" is not even a good name for the package containing that classes (they are not api, IMO. and they are very "james" specific). > API package in mailetcontainer-library should be moved to new module > - > > Key: JAMES-1282 > URL: https://issues.apache.org/jira/browse/JAMES-1282 > Project: JAMES Server > Issue Type: Task > Components: SpoolManager & Processors >Affects Versions: 3.0-M2 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 3.0-beta1 > > > To better seperate the implementation from the api its necessary to move the > API package out of mailetcontainer-library to its extra module -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1269) Create a correct NOTICE/LICENSE files for the spring binary artifact (currently having bad contents)
[ https://issues.apache.org/jira/browse/JAMES-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051085#comment-13051085 ] Stefano Bagnara commented on JAMES-1269: I worked around the issue: instead of documenting the licensing I've been able to remove all of the artifact listed under the "an unknown organization" section ;-) Robert, you say "everything else in the distribution which isn't described in the LICENSE needs to be reviewed". Can you tell what artifacts did you already checked and what is missing? > Create a correct NOTICE/LICENSE files for the spring binary artifact > (currently having bad contents) > > > Key: JAMES-1269 > URL: https://issues.apache.org/jira/browse/JAMES-1269 > Project: JAMES Server > Issue Type: Bug >Affects Versions: 3.0-M2 >Reporter: Stefano Bagnara >Priority: Blocker > Fix For: 3.0-beta1 > > Attachments: DEPENDENCIES > > > Our first attempt to release beta1 didn't include a LICENSE/NOTICE at all. > Current trunk includes a plain LICENSE/NOTICE tuple with just ASF > "references". > We have to reintroduce complete LICENSE/NOTICE files in the binary > distribution as we include third party dependencies in that package. > Subtask: we have to make sure we correctly document the way JSW artifacts are > included and what their license is (and the fact that appassembler doesn't > include licensing informations about itself and the JSW content they took > from the tanuki wrapper). > I uploaded the tanuki wrapper version 3.2.3 I obtained under the MIT license > here: > http://people.apache.org/~bago/third-party/ > I compared the content of "my" wrapper with the content in the > "org\codehaus\mojo\appassembler\daemon\jsw" folder inside the > org.codehaus.mojo/appassembler-maven-plugin-1.0.jar maven plugin (the files > our build process includes in the binary) and they are bitwise identical. > So we have to review the lib folder from the current trunk and make sure we > correclty identify LICENSE/NOTICE requirement for them (for sure we have to > add the MIT licensing for the tanuki wrapper code we include, but probably we > have other artifacts to be attributed to the copyright holders and the > respective licenses under we redistribute them). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1269) Create a correct NOTICE/LICENSE files for the spring binary artifact (currently having bad contents)
[ https://issues.apache.org/jira/browse/JAMES-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051015#comment-13051015 ] Stefano Bagnara commented on JAMES-1269: I'm stuck at the jaxb-impl jar. Downloading the jar from jaxb.java.net gives me a big jar, once "installed" I find a big folder including the jar we bundle and much more. This big folder has a License.txt including the CDDL+GPL+ClassException license and then has ThirdPartyLicenseReadme.txt including a lot of licenses for stuff in the folder. My main concern is about "XML-NamespaceSupport" under the "Artistic License" but I can't understand if this is a licensing for something else in that folder or if it is the licesing for some code used for the jar we really use. > Create a correct NOTICE/LICENSE files for the spring binary artifact > (currently having bad contents) > > > Key: JAMES-1269 > URL: https://issues.apache.org/jira/browse/JAMES-1269 > Project: JAMES Server > Issue Type: Bug >Affects Versions: 3.0-M2 >Reporter: Stefano Bagnara >Priority: Blocker > Fix For: 3.0-beta1 > > Attachments: DEPENDENCIES > > > Our first attempt to release beta1 didn't include a LICENSE/NOTICE at all. > Current trunk includes a plain LICENSE/NOTICE tuple with just ASF > "references". > We have to reintroduce complete LICENSE/NOTICE files in the binary > distribution as we include third party dependencies in that package. > Subtask: we have to make sure we correctly document the way JSW artifacts are > included and what their license is (and the fact that appassembler doesn't > include licensing informations about itself and the JSW content they took > from the tanuki wrapper). > I uploaded the tanuki wrapper version 3.2.3 I obtained under the MIT license > here: > http://people.apache.org/~bago/third-party/ > I compared the content of "my" wrapper with the content in the > "org\codehaus\mojo\appassembler\daemon\jsw" folder inside the > org.codehaus.mojo/appassembler-maven-plugin-1.0.jar maven plugin (the files > our build process includes in the binary) and they are bitwise identical. > So we have to review the lib folder from the current trunk and make sure we > correclty identify LICENSE/NOTICE requirement for them (for sure we have to > add the MIT licensing for the tanuki wrapper code we include, but probably we > have other artifacts to be attributed to the copyright holders and the > respective licenses under we redistribute them). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1269) Create a correct NOTICE/LICENSE files for the spring binary artifact (currently having bad contents)
[ https://issues.apache.org/jira/browse/JAMES-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049119#comment-13049119 ] Stefano Bagnara commented on JAMES-1269: The assembly creates a "DEPENDENCIES" file using data from dependencies poms and data specified in the supplemental-models.xml file. Probably that file can be used as a reference to copy text for the LICENSE and NOTICE files. It would be good to have a quick reference to know what licenses requires attribution text in NOTICE and what instead simply requires a reference to the license in the LICENSE file. It's weird no one attempted to write a maven plugin to take care of this: for a skilled maven plugin developer it should be really easy to do. Maybe such a tool would give a false sense of "compliance", don't know. > Create a correct NOTICE/LICENSE files for the spring binary artifact > (currently having bad contents) > > > Key: JAMES-1269 > URL: https://issues.apache.org/jira/browse/JAMES-1269 > Project: JAMES Server > Issue Type: Bug >Affects Versions: 3.0-M2 >Reporter: Stefano Bagnara >Priority: Blocker > Fix For: 3.0-beta1 > > > Our first attempt to release beta1 didn't include a LICENSE/NOTICE at all. > Current trunk includes a plain LICENSE/NOTICE tuple with just ASF > "references". > We have to reintroduce complete LICENSE/NOTICE files in the binary > distribution as we include third party dependencies in that package. > Subtask: we have to make sure we correctly document the way JSW artifacts are > included and what their license is (and the fact that appassembler doesn't > include licensing informations about itself and the JSW content they took > from the tanuki wrapper). > I uploaded the tanuki wrapper version 3.2.3 I obtained under the MIT license > here: > http://people.apache.org/~bago/third-party/ > I compared the content of "my" wrapper with the content in the > "org\codehaus\mojo\appassembler\daemon\jsw" folder inside the > org.codehaus.mojo/appassembler-maven-plugin-1.0.jar maven plugin (the files > our build process includes in the binary) and they are bitwise identical. > So we have to review the lib folder from the current trunk and make sure we > correclty identify LICENSE/NOTICE requirement for them (for sure we have to > add the MIT licensing for the tanuki wrapper code we include, but probably we > have other artifacts to be attributed to the copyright holders and the > respective licenses under we redistribute them). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1269) Create a correct NOTICE/LICENSE files for the spring binary artifact (currently having bad contents)
[ https://issues.apache.org/jira/browse/JAMES-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048745#comment-13048745 ] Stefano Bagnara commented on JAMES-1269: Not sure when I will have enough time for the whole task. So if you have time go ahead. If I don't see this task assigned I will assign to me as soon as I find some time to do some progress. > Create a correct NOTICE/LICENSE files for the spring binary artifact > (currently having bad contents) > > > Key: JAMES-1269 > URL: https://issues.apache.org/jira/browse/JAMES-1269 > Project: JAMES Server > Issue Type: Bug >Affects Versions: 3.0-M2 >Reporter: Stefano Bagnara >Priority: Blocker > Fix For: 3.0-beta1 > > > Our first attempt to release beta1 didn't include a LICENSE/NOTICE at all. > Current trunk includes a plain LICENSE/NOTICE tuple with just ASF > "references". > We have to reintroduce complete LICENSE/NOTICE files in the binary > distribution as we include third party dependencies in that package. > Subtask: we have to make sure we correctly document the way JSW artifacts are > included and what their license is (and the fact that appassembler doesn't > include licensing informations about itself and the JSW content they took > from the tanuki wrapper). > I uploaded the tanuki wrapper version 3.2.3 I obtained under the MIT license > here: > http://people.apache.org/~bago/third-party/ > I compared the content of "my" wrapper with the content in the > "org\codehaus\mojo\appassembler\daemon\jsw" folder inside the > org.codehaus.mojo/appassembler-maven-plugin-1.0.jar maven plugin (the files > our build process includes in the binary) and they are bitwise identical. > So we have to review the lib folder from the current trunk and make sure we > correclty identify LICENSE/NOTICE requirement for them (for sure we have to > add the MIT licensing for the tanuki wrapper code we include, but probably we > have other artifacts to be attributed to the copyright holders and the > respective licenses under we redistribute them). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-1269) Create a correct NOTICE/LICENSE files for the spring binary artifact (currently having bad contents)
Create a correct NOTICE/LICENSE files for the spring binary artifact (currently having bad contents) Key: JAMES-1269 URL: https://issues.apache.org/jira/browse/JAMES-1269 Project: JAMES Server Issue Type: Bug Affects Versions: 3.0-M2 Reporter: Stefano Bagnara Priority: Blocker Fix For: 3.0-beta1 Our first attempt to release beta1 didn't include a LICENSE/NOTICE at all. Current trunk includes a plain LICENSE/NOTICE tuple with just ASF "references". We have to reintroduce complete LICENSE/NOTICE files in the binary distribution as we include third party dependencies in that package. Subtask: we have to make sure we correctly document the way JSW artifacts are included and what their license is (and the fact that appassembler doesn't include licensing informations about itself and the JSW content they took from the tanuki wrapper). I uploaded the tanuki wrapper version 3.2.3 I obtained under the MIT license here: http://people.apache.org/~bago/third-party/ I compared the content of "my" wrapper with the content in the "org\codehaus\mojo\appassembler\daemon\jsw" folder inside the org.codehaus.mojo/appassembler-maven-plugin-1.0.jar maven plugin (the files our build process includes in the binary) and they are bitwise identical. So we have to review the lib folder from the current trunk and make sure we correclty identify LICENSE/NOTICE requirement for them (for sure we have to add the MIT licensing for the tanuki wrapper code we include, but probably we have other artifacts to be attributed to the copyright holders and the respective licenses under we redistribute them). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1237) Reorganize system configuration files (spring context, xsd)
[ https://issues.apache.org/jira/browse/JAMES-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032063#comment-13032063 ] Stefano Bagnara commented on JAMES-1237: I can't find @Inject annotations in the mailbox source tree. About transactions I'm not sure I understand your concerns. I don't see the way a spring or guice module will help too much developers for mailbox (instead I believe there is much to do in this regard in java code instead), but anyway you proposed separated modules so in the worst case it won't hurt. So go ahead, I will be happy to review the code and I hope to be surprised :-) > Reorganize system configuration files (spring context, xsd) > --- > > Key: JAMES-1237 > URL: https://issues.apache.org/jira/browse/JAMES-1237 > Project: JAMES Server > Issue Type: Improvement > Components: Deployment Modules >Reporter: Eric Charles > > There is a trend for configuration/properties files to be placed in META-INF > (look at cxf, camel, maven,... distributions). > Also, I think the injection of dependent project (mailbox, imap) should not > be defined in server, but in the project it self. > We could have the same approach and define a META-INF/james to hold those > files > The server context could go to META-INF/james/server-spring.xml, and we could > move the definitions related to mailbox,imap to their respective project > (with the same strategy, in META-INF/james/mailbox-spring.xml,...) > For the embedded XSD I'm not sure if thy need to go to > META-INF/james/org.apache.activemq,... or META-INF/activemq/ > In all cases, the user can stilll override the defintions at deployment time > simply by defining the files in the conf folder (conf is on top of the > classpath). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1237) Reorganize system configuration files (spring context, xsd)
[ https://issues.apache.org/jira/browse/JAMES-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031764#comment-13031764 ] Stefano Bagnara commented on JAMES-1237: "btw, you interact, so you're not that "passive" :) " words don't count as activity, they can even be counterproductive if the don't bring value, so you are authorized to ignore me as long as I don't put my hands in the code :-) "to have a library that can be used out-of-the box, without caring which bean must be injected in which other bean. " I agree with this, but I thought this could be achieved by adding a simple java class that does the wiring. Most of the stuff we wire doesn't have alternative implementations or special configurations. Adding a class with setters or constructor parameters will allow anyone to use it without caring of wiring (even people not using a DI framework that simply will call "new MainClass()" or "MainClass.newMailbox" or anything you like.. both spring and guice will deal with that easily). > Reorganize system configuration files (spring context, xsd) > --- > > Key: JAMES-1237 > URL: https://issues.apache.org/jira/browse/JAMES-1237 > Project: JAMES Server > Issue Type: Improvement > Components: Deployment Modules >Reporter: Eric Charles > > There is a trend for configuration/properties files to be placed in META-INF > (look at cxf, camel, maven,... distributions). > Also, I think the injection of dependent project (mailbox, imap) should not > be defined in server, but in the project it self. > We could have the same approach and define a META-INF/james to hold those > files > The server context could go to META-INF/james/server-spring.xml, and we could > move the definitions related to mailbox,imap to their respective project > (with the same strategy, in META-INF/james/mailbox-spring.xml,...) > For the embedded XSD I'm not sure if thy need to go to > META-INF/james/org.apache.activemq,... or META-INF/activemq/ > In all cases, the user can stilll override the defintions at deployment time > simply by defining the files in the conf folder (conf is on top of the > classpath). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1237) Reorganize system configuration files (spring context, xsd)
[ https://issues.apache.org/jira/browse/JAMES-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031733#comment-13031733 ] Stefano Bagnara commented on JAMES-1237: What did changes to make you switch to "must-have" ? I'm still in the "not a good idea" state, so I'd be happy to understand what are the points that moved you. Most spring code in james server related to imap and mailbox is james-server specific and adding more spring stuff in mailbox and imap won't help reducing the spring code in server. What are the "demployment options" that this would bring? I don't see what a mailbox-spring and mailbox-guice modules would provide to the end user/developers, and having such modules sounds countrary to the spirit of guice/spring. About your examples: cfx, camel, activemq , they embrace spring as their platform and not simply use it as "an optional, agnostic, container". I think this is something to take into consideration. They define impoved syntaxes (DSL) for spring configuration files, adapters for spring types and much more. I don't think that mailbox needs this stuff (and imap doesn't seem to have much more configuration). Currently we are far from using spring this way.. I think you are over-rating the power of adding a mailbox-spring.xml file in the mailbox project. If the goal is to help developers use the mailbox library then the api should be made more easy (there is plenty to do as suggested in the thread I linked previously). That said, you are active, I'm passive, so you should simply go ahead with your idea. I'm sure we'll better understand the advantages/disadvantages once something is done for real. > Reorganize system configuration files (spring context, xsd) > --- > > Key: JAMES-1237 > URL: https://issues.apache.org/jira/browse/JAMES-1237 > Project: JAMES Server > Issue Type: Improvement > Components: Deployment Modules >Reporter: Eric Charles > > There is a trend for configuration/properties files to be placed in META-INF > (look at cxf, camel, maven,... distributions). > Also, I think the injection of dependent project (mailbox, imap) should not > be defined in server, but in the project it self. > We could have the same approach and define a META-INF/james to hold those > files > The server context could go to META-INF/james/server-spring.xml, and we could > move the definitions related to mailbox,imap to their respective project > (with the same strategy, in META-INF/james/mailbox-spring.xml,...) > For the embedded XSD I'm not sure if thy need to go to > META-INF/james/org.apache.activemq,... or META-INF/activemq/ > In all cases, the user can stilll override the defintions at deployment time > simply by defining the files in the conf folder (conf is on top of the > classpath). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1237) Reorganize system configuration files (spring context, xsd)
[ https://issues.apache.org/jira/browse/JAMES-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031648#comment-13031648 ] Stefano Bagnara commented on JAMES-1237: About the "mailbox spring" stuff, we discussed it in the mailing list few months ago and you agreed that "having spring modules is a bit bloated for mailbox and imap". Did you change your mind? http://www.mail-archive.com/server-dev@james.apache.org/msg31051.html > Reorganize system configuration files (spring context, xsd) > --- > > Key: JAMES-1237 > URL: https://issues.apache.org/jira/browse/JAMES-1237 > Project: JAMES Server > Issue Type: Improvement > Components: Deployment Modules >Reporter: Eric Charles > > There is a trend for configuration/properties files to be placed in META-INF > (look at cxf, camel, maven,... distributions). > Also, I think the injection of dependent project (mailbox, imap) should not > be defined in server, but in the project it self. > We could have the same approach and define a META-INF/james to hold those > files > The server context could go to META-INF/james/server-spring.xml, and we could > move the definitions related to mailbox,imap to their respective project > (with the same strategy, in META-INF/james/mailbox-spring.xml,...) > For the embedded XSD I'm not sure if thy need to go to > META-INF/james/org.apache.activemq,... or META-INF/activemq/ > In all cases, the user can stilll override the defintions at deployment time > simply by defining the files in the conf folder (conf is on top of the > classpath). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-711) Reformat James sources to remove bad style
[ https://issues.apache.org/jira/browse/JAMES-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015392#comment-13015392 ] Stefano Bagnara commented on JAMES-711: --- @Felix: I agree. just wanted to warn you about the issue with blind "automatic formatting" of full code folders. I also saw projects having some stuff in the pom.xml so to put formatting.xml and codetemplates.xml into the eclipse workspace, but never investigated how it worked: https://svn.apache.org/repos/asf/camel/trunk/etc/pom.xml > Reformat James sources to remove bad style > -- > > Key: JAMES-711 > URL: https://issues.apache.org/jira/browse/JAMES-711 > Project: JAMES Server > Issue Type: Task >Affects Versions: 3.0 >Reporter: Stefano Bagnara >Assignee: Felix Knecht >Priority: Trivial > Fix For: 3.0-M3 > > > We have a lot of code that does not follow the coding style we're using > Moslty bad number of spaces and open brackets in the newline instead of the > end of the previous line. > At least in the whole IMAP code and other "active" code we should run a > reformat to keep "style" consistent. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-711) Reformat James sources to remove bad style
[ https://issues.apache.org/jira/browse/JAMES-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015334#comment-13015334 ] Stefano Bagnara commented on JAMES-711: --- I'm almost sure there are comments using spacing with sense and they will be unreadable after an automatic reformat. So, either you check every file or IMO it is better to reformat the files whenever we need to update them so we put the needed care to comments and similar. > Reformat James sources to remove bad style > -- > > Key: JAMES-711 > URL: https://issues.apache.org/jira/browse/JAMES-711 > Project: JAMES Server > Issue Type: Task >Affects Versions: 3.0 >Reporter: Stefano Bagnara >Assignee: Felix Knecht >Priority: Trivial > Fix For: 3.0-M3 > > > We have a lot of code that does not follow the coding style we're using > Moslty bad number of spaces and open brackets in the newline instead of the > end of the previous line. > At least in the whole IMAP code and other "active" code we should run a > reformat to keep "style" consistent. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (JDKIM-27) Put James JDKIM into Maven
[ https://issues.apache.org/jira/browse/JDKIM-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara updated JDKIM-27: - Affects Version/s: (was: 1.0) Fix Version/s: 0.2 > Put James JDKIM into Maven > -- > > Key: JDKIM-27 > URL: https://issues.apache.org/jira/browse/JDKIM-27 > Project: JAMES jDKIM > Issue Type: New Feature > Components: library, mailet >Affects Versions: 0.2 >Reporter: Al Briggs > Labels: build, maven > Fix For: 0.2 > > Original Estimate: 24h > Remaining Estimate: 24h > > It seems the project has not been active since 2009 - but as the library is > still useful it would be much better to have it in Maven so that it can be > more easily used. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JDKIM-28) DKIMSign and DKIMVerify mailets don't work by default in JAMES
[ https://issues.apache.org/jira/browse/JDKIM-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara resolved JDKIM-28. -- Resolution: Fixed > DKIMSign and DKIMVerify mailets don't work by default in JAMES > -- > > Key: JDKIM-28 > URL: https://issues.apache.org/jira/browse/JDKIM-28 > Project: JAMES jDKIM > Issue Type: Bug >Affects Versions: 0.2 >Reporter: Stefano Bagnara >Assignee: Stefano Bagnara >Priority: Critical > Fix For: 0.2 > > > By default javamail works with LF line separators. > When we use message.writeTo end of lines are LF. Instead when SMTPTransport > sends the message to another server it introduce a CRLFOutputStream in the > middle so to respect the RFC. > DKIM says that it is possible to sign only CRLF messages. As it is hard to > change the CRLF before the mailet we should better compute hashes as if LF > were CRLF so that when sent the message will be ok (the same is true for > verifier too). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JDKIM-28) DKIMSign and DKIMVerify mailets don't work by default in JAMES
DKIMSign and DKIMVerify mailets don't work by default in JAMES -- Key: JDKIM-28 URL: https://issues.apache.org/jira/browse/JDKIM-28 Project: JAMES jDKIM Issue Type: Bug Affects Versions: 0.2 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Priority: Critical Fix For: 0.2 By default javamail works with LF line separators. When we use message.writeTo end of lines are LF. Instead when SMTPTransport sends the message to another server it introduce a CRLFOutputStream in the middle so to respect the RFC. DKIM says that it is possible to sign only CRLF messages. As it is hard to change the CRLF before the mailet we should better compute hashes as if LF were CRLF so that when sent the message will be ok (the same is true for verifier too). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JSIEVE-74) Script parsing fails when the string contains a backslash
[
https://issues.apache.org/jira/browse/JSIEVE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefano Bagnara resolved JSIEVE-74.
---
Resolution: Fixed
Fix Version/s: 0.5
Patch applied, thank you Vishal.
> Script parsing fails when the string contains a backslash
> -
>
> Key: JSIEVE-74
> URL: https://issues.apache.org/jira/browse/JSIEVE-74
> Project: JAMES jSieve
> Issue Type: Bug
> Components: JSieve (Main)
>Affects Versions: 0.3
>Reporter: Boris Burtin
>Assignee: Stefano Bagnara
> Fix For: 0.5
>
> Attachments: backslash-rule.sieve, patch.txt
>
>
> The following script fails to parse because one of the string literals
> contains a backslash. The parser also reports an error in the wrong line.
> require ["fileinto", "reject", "tag", "flag"];
> # test
> if allof (header :contains "to" "\\") {
> keep;
> stop;
> }
> # test2
> if anyof (header :contains "subject" "foo") {
> keep;
> stop;
> }
> org.apache.jsieve.parser.generated.TokenMgrError: Lexical error at line 14,
> column 0. Encountered: after : "\") {\nkeep;\nstop;\n}\n"
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JSIEVE-75) incorrect parsing of script containing multiple multi-line forms
[
https://issues.apache.org/jira/browse/JSIEVE-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefano Bagnara resolved JSIEVE-75.
---
Resolution: Fixed
Fix Version/s: 0.5
@Vishal: I just applied the patch.
I see the grammar still deal with isolated \n and \r treating them as newline
in various places.
I have no pratical knowledge of sieve scripts in the wild so I don't know if it
is better to leave the "permissive" grammar or instead if it is better to be
strict with CRLF (people can simply put an input filter before reading the
script to replace lonely \r or \n with \r\n: we have an
EolConvertingInputStream in mime4j for example).
WDYT?
> incorrect parsing of script containing multiple multi-line forms
>
>
> Key: JSIEVE-75
> URL: https://issues.apache.org/jira/browse/JSIEVE-75
> Project: JAMES jSieve
> Issue Type: Bug
> Components: JSieve (Main)
>Affects Versions: 0.4
>Reporter: Vishal Mahajan
>Assignee: Stefano Bagnara
>Priority: Critical
> Fix For: 0.5
>
> Attachments: patch.txt
>
>
> I am using jSieve 0.4. I have the following sieve script containing two
> multi-line forms:
>
> require ["fileinto", "reject", "tag", "flag"];
> # filter1
> if anyof (header :contains "subject" "abc") {
> reply text:
> reply1
> .
> ;
> reply text:
> reply2
> .
> ;
> }
>
> The issue is that the jSieve parser sees only one multi-line form in the
> above script, with form data being the text between the first "text:" and
> last "CRLF.CRLF", i.e.
>
> reply1
> .
> ;
> reply text:
> reply2
>
> Is there an issue in the sieve.jjt grammar in dealing with multiple
> multi-line forms?
> One of the odd things I observed in sieve.jjt is that NEWLINE is considered
> as "\n"|"\r"|"\r\n", whereas RFC 3028 (section 2.4.2) requires that a
> multi-line form:
> starts with the keyword "text:",
> followed by a CRLF, and ends with the sequence of a CRLF, a single
> period, and another CRLF.
> which implies that standalone "\n" and "\r" chars should not be considered in
> determining start and end of multi-line form data.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Assigned] (JSIEVE-74) Script parsing fails when the string contains a backslash
[
https://issues.apache.org/jira/browse/JSIEVE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefano Bagnara reassigned JSIEVE-74:
-
Assignee: Stefano Bagnara (was: Norman Maurer)
> Script parsing fails when the string contains a backslash
> -
>
> Key: JSIEVE-74
> URL: https://issues.apache.org/jira/browse/JSIEVE-74
> Project: JAMES jSieve
> Issue Type: Bug
> Components: JSieve (Main)
>Affects Versions: 0.3
>Reporter: Boris Burtin
>Assignee: Stefano Bagnara
> Attachments: backslash-rule.sieve, patch.txt
>
>
> The following script fails to parse because one of the string literals
> contains a backslash. The parser also reports an error in the wrong line.
> require ["fileinto", "reject", "tag", "flag"];
> # test
> if allof (header :contains "to" "\\") {
> keep;
> stop;
> }
> # test2
> if anyof (header :contains "subject" "foo") {
> keep;
> stop;
> }
> org.apache.jsieve.parser.generated.TokenMgrError: Lexical error at line 14,
> column 0. Encountered: after : "\") {\nkeep;\nstop;\n}\n"
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Assigned] (JSIEVE-75) incorrect parsing of script containing multiple multi-line forms
[
https://issues.apache.org/jira/browse/JSIEVE-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefano Bagnara reassigned JSIEVE-75:
-
Assignee: Stefano Bagnara
> incorrect parsing of script containing multiple multi-line forms
>
>
> Key: JSIEVE-75
> URL: https://issues.apache.org/jira/browse/JSIEVE-75
> Project: JAMES jSieve
> Issue Type: Bug
> Components: JSieve (Main)
>Affects Versions: 0.4
>Reporter: Vishal Mahajan
>Assignee: Stefano Bagnara
>Priority: Critical
> Attachments: patch.txt
>
>
> I am using jSieve 0.4. I have the following sieve script containing two
> multi-line forms:
>
> require ["fileinto", "reject", "tag", "flag"];
> # filter1
> if anyof (header :contains "subject" "abc") {
> reply text:
> reply1
> .
> ;
> reply text:
> reply2
> .
> ;
> }
>
> The issue is that the jSieve parser sees only one multi-line form in the
> above script, with form data being the text between the first "text:" and
> last "CRLF.CRLF", i.e.
>
> reply1
> .
> ;
> reply text:
> reply2
>
> Is there an issue in the sieve.jjt grammar in dealing with multiple
> multi-line forms?
> One of the odd things I observed in sieve.jjt is that NEWLINE is considered
> as "\n"|"\r"|"\r\n", whereas RFC 3028 (section 2.4.2) requires that a
> multi-line form:
> starts with the keyword "text:",
> followed by a CRLF, and ends with the sequence of a CRLF, a single
> period, and another CRLF.
> which implies that standalone "\n" and "\r" chars should not be considered in
> determining start and end of multi-line form data.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (JAMES-1184) Modules consolidation
[
https://issues.apache.org/jira/browse/JAMES-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefano Bagnara resolved JAMES-1184.
Resolution: Fixed
Marking resolved as we did everything we agreed upon.
> Modules consolidation
> -
>
> Key: JAMES-1184
> URL: https://issues.apache.org/jira/browse/JAMES-1184
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
>Affects Versions: 3.0-M2
>Reporter: Stefano Bagnara
>Assignee: Stefano Bagnara
> Fix For: 3.0-M3
>
> Attachments: graph-server-deps-edited.gif, graph-server-utils.gif,
> graph-server.gif
>
>
> Just opening it to keep track of the proposal to the mailing list.
>
> - mail-file(3)
> - mail-jcr(1)
> - mail-jdbc(3)
> - user-jpa(4)
> - user-file(2)
> - user-jcr(2)
> - user-jdbc(4)
> - domainlist-jpa(2)
> - domainlist-xml(1)
> I only see benefits and no drawbacks in consolidating the 9 modules
> above to the following 4 modules:
> persistence-jpa(6) = user-jpa(4)+domainlist-jpa(2)
> persistence-file(6) = user-file(2)+mail-file(3)+domainlist-xml(1)
> persistence-jcr(3) = user-jcr(2)+mail-jcr(1)
> persistence-jdbc(7) = user-jdbc(4)+mail-jdbc(3)
> - mail-library(1)
> - domainlist-library(2)
> - user-library(9)
> We could consolidate them into a persistence-library module (from 3 to
> 1 module).
> persistence-library(12) =
> mail-library(1)+domainlist-library(2)+user-library(9)
> - queue-library(2)
> - queue-jms(5)
> We could merge queue-library to queue-jms (a library module makes
> sense when we do something useful.. if it is trivial stuff it can be
> duplicated or moved to the api layer).
> queue-jms(7) = queue-jms(5)+queue-library(2)
> -
> It seems there is agreement on the merging. We still have to decide whether
> to name the modules "persistence-${type}" or simply "${type}" (or maybe
> "data-${type}")
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JDKIM-26) java.lang.StackOverflowError runtime exception
[ https://issues.apache.org/jira/browse/JDKIM-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989840#comment-12989840 ] Stefano Bagnara commented on JDKIM-26: -- You have to build it on your own. Unfortunately jDKIM trunk depends on a version of Mime4J that is not released nor available right now. Mime4j snapshots have evolved in an incompatible way so jDKIM doesn't build anymore against the latest Mime4j snapshot. I'm sorry I don't have a fast fix to provide a working build (I have a local mime4j snapshot from 1 month ago and I'm building against it). > java.lang.StackOverflowError runtime exception > --- > > Key: JDKIM-26 > URL: https://issues.apache.org/jira/browse/JDKIM-26 > Project: JAMES jDKIM > Issue Type: Bug > Components: library >Affects Versions: 0.2, 1.0 > Environment: ubuntu 10.04 > java version "1.6.0_20" >Reporter: Ben Aldrich >Assignee: Stefano Bagnara >Priority: Critical > Fix For: 0.2 > > Attachments: comcast.hostfailed.201009011204 > > > When parsing an unusual dkim signature this exception is thrown: > java.lang.StackOverflowError > at java.util.regex.Pattern$Slice.match(Pattern.java:3499) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4328) > at java.util.regex.Pattern$Prolog.match(Pattern.java:4268) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$Curly.match0(Pattern.java:3799) > at java.util.regex.Pattern$Curly.match(Pattern.java:3761) > at java.util.regex.Pattern$Loop.match(Pattern.java:4321) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$BranchConn.match(Pattern.java:4095) > at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3383) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$BranchConn.match(Pattern.java:4095) > at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3383) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$BranchConn.match(Pattern.java:4095) > at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3383) > at java.util.regex.Pattern$Slice.match(Pattern.java:3499) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4328) > at java.util.regex.Pattern$Prolog.match(Pattern.java:4268) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > I have uploaded the message causing the issue, I am getting email like this a > couple times a week crashing dkim validation. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (JDKIM-26) java.lang.StackOverflowError runtime exception
[ https://issues.apache.org/jira/browse/JDKIM-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara resolved JDKIM-26. -- Resolution: Fixed Fix Version/s: 0.2 Fixed by optimizing the regexp to use possessive qualifiers for variable length matching. > java.lang.StackOverflowError runtime exception > --- > > Key: JDKIM-26 > URL: https://issues.apache.org/jira/browse/JDKIM-26 > Project: JAMES jDKIM > Issue Type: Bug > Components: library >Affects Versions: 0.2, 1.0 > Environment: ubuntu 10.04 > java version "1.6.0_20" >Reporter: Ben Aldrich >Assignee: Stefano Bagnara >Priority: Critical > Fix For: 0.2 > > Attachments: comcast.hostfailed.201009011204 > > > When parsing an unusual dkim signature this exception is thrown: > java.lang.StackOverflowError > at java.util.regex.Pattern$Slice.match(Pattern.java:3499) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4328) > at java.util.regex.Pattern$Prolog.match(Pattern.java:4268) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$Curly.match0(Pattern.java:3799) > at java.util.regex.Pattern$Curly.match(Pattern.java:3761) > at java.util.regex.Pattern$Loop.match(Pattern.java:4321) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$BranchConn.match(Pattern.java:4095) > at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3383) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$BranchConn.match(Pattern.java:4095) > at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3383) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$BranchConn.match(Pattern.java:4095) > at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3383) > at java.util.regex.Pattern$Slice.match(Pattern.java:3499) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4328) > at java.util.regex.Pattern$Prolog.match(Pattern.java:4268) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > I have uploaded the message causing the issue, I am getting email like this a > couple times a week crashing dkim validation. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Assigned: (JDKIM-26) java.lang.StackOverflowError runtime exception
[ https://issues.apache.org/jira/browse/JDKIM-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara reassigned JDKIM-26: Assignee: Stefano Bagnara > java.lang.StackOverflowError runtime exception > --- > > Key: JDKIM-26 > URL: https://issues.apache.org/jira/browse/JDKIM-26 > Project: JAMES jDKIM > Issue Type: Bug > Components: library >Affects Versions: 0.2, 1.0 > Environment: ubuntu 10.04 > java version "1.6.0_20" >Reporter: Ben Aldrich >Assignee: Stefano Bagnara >Priority: Critical > Attachments: comcast.hostfailed.201009011204 > > > When parsing an unusual dkim signature this exception is thrown: > java.lang.StackOverflowError > at java.util.regex.Pattern$Slice.match(Pattern.java:3499) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4328) > at java.util.regex.Pattern$Prolog.match(Pattern.java:4268) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$Curly.match0(Pattern.java:3799) > at java.util.regex.Pattern$Curly.match(Pattern.java:3761) > at java.util.regex.Pattern$Loop.match(Pattern.java:4321) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$BranchConn.match(Pattern.java:4095) > at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3383) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$BranchConn.match(Pattern.java:4095) > at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3383) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$BranchConn.match(Pattern.java:4095) > at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3383) > at java.util.regex.Pattern$Slice.match(Pattern.java:3499) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4328) > at java.util.regex.Pattern$Prolog.match(Pattern.java:4268) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > I have uploaded the message causing the issue, I am getting email like this a > couple times a week crashing dkim validation. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JDKIM-26) java.lang.StackOverflowError runtime exception
[ https://issues.apache.org/jira/browse/JDKIM-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989590#comment-12989590 ] Stefano Bagnara commented on JDKIM-26: -- So, it seems the issue is during the VALIDATION of the attributes. I tried to change the "protected static final boolean VALIDATION = true;" to false and it now runs (even if the signatures are both invalid). It seems some java regex bug in the valuePattern matching. I'm trying to optimize the regex using some hint to avoid heavy stack usage. > java.lang.StackOverflowError runtime exception > --- > > Key: JDKIM-26 > URL: https://issues.apache.org/jira/browse/JDKIM-26 > Project: JAMES jDKIM > Issue Type: Bug > Components: library >Affects Versions: 0.2, 1.0 > Environment: ubuntu 10.04 > java version "1.6.0_20" >Reporter: Ben Aldrich >Priority: Critical > Attachments: comcast.hostfailed.201009011204 > > > When parsing an unusual dkim signature this exception is thrown: > java.lang.StackOverflowError > at java.util.regex.Pattern$Slice.match(Pattern.java:3499) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4328) > at java.util.regex.Pattern$Prolog.match(Pattern.java:4268) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$Curly.match0(Pattern.java:3799) > at java.util.regex.Pattern$Curly.match(Pattern.java:3761) > at java.util.regex.Pattern$Loop.match(Pattern.java:4321) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$BranchConn.match(Pattern.java:4095) > at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3383) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$BranchConn.match(Pattern.java:4095) > at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3383) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > at java.util.regex.Pattern$BranchConn.match(Pattern.java:4095) > at java.util.regex.Pattern$BmpCharProperty.match(Pattern.java:3383) > at java.util.regex.Pattern$Slice.match(Pattern.java:3499) > at java.util.regex.Pattern$Branch.match(Pattern.java:4131) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.matchInit(Pattern.java:4328) > at java.util.regex.Pattern$Prolog.match(Pattern.java:4268) > at java.util.regex.Pattern$GroupHead.match(Pattern.java:4185) > at java.util.regex.Pattern$Loop.match(Pattern.java:4312) > at java.util.regex.Pattern$GroupTail.match(Pattern.java:4244) > I have uploaded the message causing the issue, I am getting email like this a > couple times a week crashing dkim validation. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (JAMES-1067) Remove dependency on commons-oro
[ https://issues.apache.org/jira/browse/JAMES-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara resolved JAMES-1067. Resolution: Fixed Fix Version/s: (was: 3.0) 3.0-M3 > Remove dependency on commons-oro > > > Key: JAMES-1067 > URL: https://issues.apache.org/jira/browse/JAMES-1067 > Project: JAMES Server > Issue Type: Task >Reporter: Norman Maurer >Assignee: Stefano Bagnara > Fix For: 3.0-M3 > > > We have a few classes which use commons oro. The dependency should get > removed because commons oro was moved to the attic. > See: > http://jakarta.apache.org/site/news/news-2010-q3.html#20100901.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-1184) Modules consolidation
[
https://issues.apache.org/jira/browse/JAMES-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984122#action_12984122
]
Stefano Bagnara commented on JAMES-1184:
@Norman about utils as library instead of api, it's not a big deal. as I wrote
it is not something I evaluated well, just wanted to write somewhere a
temporary thought and decided to do it in this public issue instead of a
private note. You answer helped me understand that it probably doesn't worth
touching it (except for the green/yellow classes that can be moved/deleted
anyway).
@Both about nested layers: I agree this need some more thinking and we should
ignore this now. Eric made a good point about looking also to external modules
and organize things from the outside not only focusing on james-server.
about queue modules: I agree that queue management is a bit different from
persistence, but If I understand it well our queues deal with persistence too.
It's not a simple queue but a spool queue. I could implement a file based queue
implementation, or a pure JDBC one (based on the SpoolRepository from james
2.3): our queue is a persistent store where you can put mail and get mails. BTW
I'm not strong on this idea that's why I haven't touch the queue-* modules in
this consolidation..
Thanks for your comments, it's getting exciting again to work on james and to
have constructive discussions! I will probably close this issue soon.
> Modules consolidation
> -
>
> Key: JAMES-1184
> URL: https://issues.apache.org/jira/browse/JAMES-1184
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
>Affects Versions: 3.0-M2
>Reporter: Stefano Bagnara
>Assignee: Stefano Bagnara
> Fix For: 3.0-M3
>
> Attachments: graph-server-deps-edited.gif, graph-server-utils.gif,
> graph-server.gif
>
>
> Just opening it to keep track of the proposal to the mailing list.
>
> - mail-file(3)
> - mail-jcr(1)
> - mail-jdbc(3)
> - user-jpa(4)
> - user-file(2)
> - user-jcr(2)
> - user-jdbc(4)
> - domainlist-jpa(2)
> - domainlist-xml(1)
> I only see benefits and no drawbacks in consolidating the 9 modules
> above to the following 4 modules:
> persistence-jpa(6) = user-jpa(4)+domainlist-jpa(2)
> persistence-file(6) = user-file(2)+mail-file(3)+domainlist-xml(1)
> persistence-jcr(3) = user-jcr(2)+mail-jcr(1)
> persistence-jdbc(7) = user-jdbc(4)+mail-jdbc(3)
> - mail-library(1)
> - domainlist-library(2)
> - user-library(9)
> We could consolidate them into a persistence-library module (from 3 to
> 1 module).
> persistence-library(12) =
> mail-library(1)+domainlist-library(2)+user-library(9)
> - queue-library(2)
> - queue-jms(5)
> We could merge queue-library to queue-jms (a library module makes
> sense when we do something useful.. if it is trivial stuff it can be
> duplicated or moved to the api layer).
> queue-jms(7) = queue-jms(5)+queue-library(2)
> -
> It seems there is agreement on the merging. We still have to decide whether
> to name the modules "persistence-${type}" or simply "${type}" (or maybe
> "data-${type}")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Updated: (JAMES-1184) Modules consolidation
[
https://issues.apache.org/jira/browse/JAMES-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefano Bagnara updated JAMES-1184:
---
Attachment: graph-server-deps-edited.gif
Forgot to share another graph I made yesterday after the second step
refactoring.
This include external jars dependencies in the chart.
It is interesting to see that our api layer have only this dependencies:
- apache-mailet
- javax.mail
- commons-logging
- commons-configuration
On the library level we add:
- protocols-api
- mailet-base
- protocols-impl
- netty
Then we have 2 shared dependencies in functions:
- jspf-resolver
- protocols-smtp
The good thing is that every other dependency is strictly isolated in a single
"function" module and I think this was the main goal of mudules, so it seems we
did it :-) (I grouped dependencies with their module when they was used just
by that module)
I hope to find some time the next weekend to put my hands on the netty stuff
(it is one of the new things I still don't know very well): I would like to see
if I can remove netty from the library layer and isolate it to a function
(using composition and maybe a new api for replacing direct inheritance).
> Modules consolidation
> -
>
> Key: JAMES-1184
> URL: https://issues.apache.org/jira/browse/JAMES-1184
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
>Affects Versions: 3.0-M2
>Reporter: Stefano Bagnara
>Assignee: Stefano Bagnara
> Fix For: 3.0-M3
>
> Attachments: graph-server-deps-edited.gif, graph-server-utils.gif,
> graph-server.gif
>
>
> Just opening it to keep track of the proposal to the mailing list.
>
> - mail-file(3)
> - mail-jcr(1)
> - mail-jdbc(3)
> - user-jpa(4)
> - user-file(2)
> - user-jcr(2)
> - user-jdbc(4)
> - domainlist-jpa(2)
> - domainlist-xml(1)
> I only see benefits and no drawbacks in consolidating the 9 modules
> above to the following 4 modules:
> persistence-jpa(6) = user-jpa(4)+domainlist-jpa(2)
> persistence-file(6) = user-file(2)+mail-file(3)+domainlist-xml(1)
> persistence-jcr(3) = user-jcr(2)+mail-jcr(1)
> persistence-jdbc(7) = user-jdbc(4)+mail-jdbc(3)
> - mail-library(1)
> - domainlist-library(2)
> - user-library(9)
> We could consolidate them into a persistence-library module (from 3 to
> 1 module).
> persistence-library(12) =
> mail-library(1)+domainlist-library(2)+user-library(9)
> - queue-library(2)
> - queue-jms(5)
> We could merge queue-library to queue-jms (a library module makes
> sense when we do something useful.. if it is trivial stuff it can be
> duplicated or moved to the api layer).
> queue-jms(7) = queue-jms(5)+queue-library(2)
> -
> It seems there is agreement on the merging. We still have to decide whether
> to name the modules "persistence-${type}" or simply "${type}" (or maybe
> "data-${type}")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-1184) Modules consolidation
[
https://issues.apache.org/jira/browse/JAMES-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983921#action_12983921
]
Stefano Bagnara commented on JAMES-1184:
About utils there is a plan to avoid having it at the api level.
In this plan:
- Green classes can be moved to the only library depending on them
(Lock+XMLResource to data-library, CombinedInputStream to core)
- Orange classes can be merged to protocol-library (most of them are JMX
classes and protocol-library is already the home for most jmx stuff). Fetchmail
will depend on protocols-library then (instead of util).
- Purple classes can be moved to a new library (not sure about the name...
maybe we can keep util and simply know that libraries do not depends anymore
from util and we can put util together with libraries in the "layers").
- Yellow classes can be removed, or left together the Purple ones.
This does not reduce the number of modules but reduce the size of the util
module and bring it at the "library" layer so in the api layer we just have
real apis.
As per the "multilevel" comment I'm just writing this as loud-thinking... just
a place to scratchpad some thought as I have no time to do better analysis of
pro/cons of both changes now
> Modules consolidation
> -
>
> Key: JAMES-1184
> URL: https://issues.apache.org/jira/browse/JAMES-1184
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
>Affects Versions: 3.0-M2
>Reporter: Stefano Bagnara
>Assignee: Stefano Bagnara
> Fix For: 3.0-M3
>
> Attachments: graph-server-utils.gif, graph-server.gif
>
>
> Just opening it to keep track of the proposal to the mailing list.
>
> - mail-file(3)
> - mail-jcr(1)
> - mail-jdbc(3)
> - user-jpa(4)
> - user-file(2)
> - user-jcr(2)
> - user-jdbc(4)
> - domainlist-jpa(2)
> - domainlist-xml(1)
> I only see benefits and no drawbacks in consolidating the 9 modules
> above to the following 4 modules:
> persistence-jpa(6) = user-jpa(4)+domainlist-jpa(2)
> persistence-file(6) = user-file(2)+mail-file(3)+domainlist-xml(1)
> persistence-jcr(3) = user-jcr(2)+mail-jcr(1)
> persistence-jdbc(7) = user-jdbc(4)+mail-jdbc(3)
> - mail-library(1)
> - domainlist-library(2)
> - user-library(9)
> We could consolidate them into a persistence-library module (from 3 to
> 1 module).
> persistence-library(12) =
> mail-library(1)+domainlist-library(2)+user-library(9)
> - queue-library(2)
> - queue-jms(5)
> We could merge queue-library to queue-jms (a library module makes
> sense when we do something useful.. if it is trivial stuff it can be
> duplicated or moved to the api layer).
> queue-jms(7) = queue-jms(5)+queue-library(2)
> -
> It seems there is agreement on the merging. We still have to decide whether
> to name the modules "persistence-${type}" or simply "${type}" (or maybe
> "data-${type}")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Updated: (JAMES-1184) Modules consolidation
[
https://issues.apache.org/jira/browse/JAMES-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefano Bagnara updated JAMES-1184:
---
Attachment: graph-server-utils.gif
I took util module into consideration and checked what module depends on what
class.
> Modules consolidation
> -
>
> Key: JAMES-1184
> URL: https://issues.apache.org/jira/browse/JAMES-1184
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
>Affects Versions: 3.0-M2
>Reporter: Stefano Bagnara
>Assignee: Stefano Bagnara
> Fix For: 3.0-M3
>
> Attachments: graph-server-utils.gif, graph-server.gif
>
>
> Just opening it to keep track of the proposal to the mailing list.
>
> - mail-file(3)
> - mail-jcr(1)
> - mail-jdbc(3)
> - user-jpa(4)
> - user-file(2)
> - user-jcr(2)
> - user-jdbc(4)
> - domainlist-jpa(2)
> - domainlist-xml(1)
> I only see benefits and no drawbacks in consolidating the 9 modules
> above to the following 4 modules:
> persistence-jpa(6) = user-jpa(4)+domainlist-jpa(2)
> persistence-file(6) = user-file(2)+mail-file(3)+domainlist-xml(1)
> persistence-jcr(3) = user-jcr(2)+mail-jcr(1)
> persistence-jdbc(7) = user-jdbc(4)+mail-jdbc(3)
> - mail-library(1)
> - domainlist-library(2)
> - user-library(9)
> We could consolidate them into a persistence-library module (from 3 to
> 1 module).
> persistence-library(12) =
> mail-library(1)+domainlist-library(2)+user-library(9)
> - queue-library(2)
> - queue-jms(5)
> We could merge queue-library to queue-jms (a library module makes
> sense when we do something useful.. if it is trivial stuff it can be
> duplicated or moved to the api layer).
> queue-jms(7) = queue-jms(5)+queue-library(2)
> -
> It seems there is agreement on the merging. We still have to decide whether
> to name the modules "persistence-${type}" or simply "${type}" (or maybe
> "data-${type}")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-1184) Modules consolidation
[
https://issues.apache.org/jira/browse/JAMES-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983893#action_12983893
]
Stefano Bagnara commented on JAMES-1184:
OK, applied step2 changes.
Norman: I didn't merge mailetcontainer-library to mailetcontainer-camel mainly
because container-spring have a direct dependency to mailetcontainer-library
and this would have moved up the container-spring module. I think it is safe to
not have direct "function" dependencies (I mean in source classes) in the
container-spring module, so for the moment I preferred to limit the change.
I added some color to identify api+util, libraries, "tcp services", "data-api
implementations" and remaining functions.
I was wondering if moving to a multilevel structure would better reflect the
layers and help users to find what they need:
---
api
dnsservice-api
filesystem-api
lifecycle-api
queue-api
data-api
util
libs
core
data-library
dnsservice-library
mailetcontainer-library
protocols-library
data
file
jcr
jdbc
jpa
queue-activemq as activemq
queue-jms as jms
ldap
protocols (or services)
imapserver
lmtpserver
pop3server
smtpserver
fetchmail
others (container? better name???)
cli
container-spring
dnsservice-dnsjava
mailbox-adapter
mailetcontainer-camel
mailets
osgi
-
The reading key is:
- Most developers will not change api or libraries modules because only core
developers need to change them.
- Most developers will be able to tweak james by just working on functions.
- If devs need special integration then they will probably have to work in the
"data" group and tweak the specific persistence adapter or simply add a new
custom module.
- If devs need to tweak protocols behaviours then they will work in protocols
and maybe on external projects (james-protocols and james-imap).
I'm still thinking more about this, but I wanted to share this thought as it is
related to code/modules organization.
> Modules consolidation
> -
>
> Key: JAMES-1184
> URL: https://issues.apache.org/jira/browse/JAMES-1184
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
>Affects Versions: 3.0-M2
>Reporter: Stefano Bagnara
>Assignee: Stefano Bagnara
> Fix For: 3.0-M3
>
> Attachments: graph-server.gif
>
>
> Just opening it to keep track of the proposal to the mailing list.
>
> - mail-file(3)
> - mail-jcr(1)
> - mail-jdbc(3)
> - user-jpa(4)
> - user-file(2)
> - user-jcr(2)
> - user-jdbc(4)
> - domainlist-jpa(2)
> - domainlist-xml(1)
> I only see benefits and no drawbacks in consolidating the 9 modules
> above to the following 4 modules:
> persistence-jpa(6) = user-jpa(4)+domainlist-jpa(2)
> persistence-file(6) = user-file(2)+mail-file(3)+domainlist-xml(1)
> persistence-jcr(3) = user-jcr(2)+mail-jcr(1)
> persistence-jdbc(7) = user-jdbc(4)+mail-jdbc(3)
> - mail-library(1)
> - domainlist-library(2)
> - user-library(9)
> We could consolidate them into a persistence-library module (from 3 to
> 1 module).
> persistence-library(12) =
> mail-library(1)+domainlist-library(2)+user-library(9)
> - queue-library(2)
> - queue-jms(5)
> We could merge queue-library to queue-jms (a library module makes
> sense when we do something useful.. if it is trivial stuff it can be
> duplicated or moved to the api layer).
> queue-jms(7) = queue-jms(5)+queue-library(2)
> -
> It seems there is agreement on the merging. We still have to decide whether
> to name the modules "persistence-${type}" or simply "${type}" (or maybe
> "data-${type}")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Updated: (JAMES-1184) Modules consolidation
[
https://issues.apache.org/jira/browse/JAMES-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefano Bagnara updated JAMES-1184:
---
Attachment: graph-server.gif
Updated dependency graph
> Modules consolidation
> -
>
> Key: JAMES-1184
> URL: https://issues.apache.org/jira/browse/JAMES-1184
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
>Affects Versions: 3.0-M2
>Reporter: Stefano Bagnara
>Assignee: Stefano Bagnara
> Fix For: 3.0-M3
>
> Attachments: graph-server.gif
>
>
> Just opening it to keep track of the proposal to the mailing list.
>
> - mail-file(3)
> - mail-jcr(1)
> - mail-jdbc(3)
> - user-jpa(4)
> - user-file(2)
> - user-jcr(2)
> - user-jdbc(4)
> - domainlist-jpa(2)
> - domainlist-xml(1)
> I only see benefits and no drawbacks in consolidating the 9 modules
> above to the following 4 modules:
> persistence-jpa(6) = user-jpa(4)+domainlist-jpa(2)
> persistence-file(6) = user-file(2)+mail-file(3)+domainlist-xml(1)
> persistence-jcr(3) = user-jcr(2)+mail-jcr(1)
> persistence-jdbc(7) = user-jdbc(4)+mail-jdbc(3)
> - mail-library(1)
> - domainlist-library(2)
> - user-library(9)
> We could consolidate them into a persistence-library module (from 3 to
> 1 module).
> persistence-library(12) =
> mail-library(1)+domainlist-library(2)+user-library(9)
> - queue-library(2)
> - queue-jms(5)
> We could merge queue-library to queue-jms (a library module makes
> sense when we do something useful.. if it is trivial stuff it can be
> duplicated or moved to the api layer).
> queue-jms(7) = queue-jms(5)+queue-library(2)
> -
> It seems there is agreement on the merging. We still have to decide whether
> to name the modules "persistence-${type}" or simply "${type}" (or maybe
> "data-${type}")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-1184) Modules consolidation
[
https://issues.apache.org/jira/browse/JAMES-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983327#action_12983327
]
Stefano Bagnara commented on JAMES-1184:
So, here I am with the second step:
One of my principles is that an api module is justified if there are at least 2
modules using it or if the api exposed is useful/cool enough to be used outside
james (and in this case I would think moving to a separate project too).
So:
A) repository-api: doesn't make sense to have an api for this. IMO it contains
simply implementation details and we should move the classes to data-library.
B) mailetcontainer-api(7) could be merged to mailetcontainer-library(16): no
component seems to deal with mailetcontainer-api, so we don't need to expose
them in a special module.
Then, given I don't see advantages in keeping them separated...
C) domainlist-api(3), mail-api(2), user-api(9) could be merged to data-api: I
don't see downstream users using only one of these api and their implementation
for something really useful outside james so I would simply follow what we did
with the libraries and merge them into a single module.
Then a couple of minor changes:
D) mailetcontainer-api jmx subpackage: why do we need this jmx at the api
level? I'd move the jmx stuff to the mailetcontainer-library module.
E) rename user-ldap to ldap: maybe in future someone will implement a readonly
domainlist via ldap (so this would work like other modules: jcr,jpa,jdbc,file).
This second step reduces the number of modules from 34 to 30.
Waiting for your feedback.
> Modules consolidation
> -
>
> Key: JAMES-1184
> URL: https://issues.apache.org/jira/browse/JAMES-1184
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
>Affects Versions: 3.0-M2
>Reporter: Stefano Bagnara
>Assignee: Stefano Bagnara
> Fix For: 3.0-M3
>
>
> Just opening it to keep track of the proposal to the mailing list.
>
> - mail-file(3)
> - mail-jcr(1)
> - mail-jdbc(3)
> - user-jpa(4)
> - user-file(2)
> - user-jcr(2)
> - user-jdbc(4)
> - domainlist-jpa(2)
> - domainlist-xml(1)
> I only see benefits and no drawbacks in consolidating the 9 modules
> above to the following 4 modules:
> persistence-jpa(6) = user-jpa(4)+domainlist-jpa(2)
> persistence-file(6) = user-file(2)+mail-file(3)+domainlist-xml(1)
> persistence-jcr(3) = user-jcr(2)+mail-jcr(1)
> persistence-jdbc(7) = user-jdbc(4)+mail-jdbc(3)
> - mail-library(1)
> - domainlist-library(2)
> - user-library(9)
> We could consolidate them into a persistence-library module (from 3 to
> 1 module).
> persistence-library(12) =
> mail-library(1)+domainlist-library(2)+user-library(9)
> - queue-library(2)
> - queue-jms(5)
> We could merge queue-library to queue-jms (a library module makes
> sense when we do something useful.. if it is trivial stuff it can be
> duplicated or moved to the api layer).
> queue-jms(7) = queue-jms(5)+queue-library(2)
> -
> It seems there is agreement on the merging. We still have to decide whether
> to name the modules "persistence-${type}" or simply "${type}" (or maybe
> "data-${type}")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-1184) Modules consolidation
[
https://issues.apache.org/jira/browse/JAMES-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983235#action_12983235
]
Stefano Bagnara commented on JAMES-1184:
I did the proposed consolidation. I also moved repository-file stuff into
data-library as it simply included some utility class used by the jdbc and file
persistence modules.
I think we need some more consolidation, so I leave this open to find some time
to have a better look expecially to the api modules.
> Modules consolidation
> -
>
> Key: JAMES-1184
> URL: https://issues.apache.org/jira/browse/JAMES-1184
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
>Affects Versions: 3.0-M2
>Reporter: Stefano Bagnara
>Assignee: Stefano Bagnara
> Fix For: 3.0-M3
>
>
> Just opening it to keep track of the proposal to the mailing list.
>
> - mail-file(3)
> - mail-jcr(1)
> - mail-jdbc(3)
> - user-jpa(4)
> - user-file(2)
> - user-jcr(2)
> - user-jdbc(4)
> - domainlist-jpa(2)
> - domainlist-xml(1)
> I only see benefits and no drawbacks in consolidating the 9 modules
> above to the following 4 modules:
> persistence-jpa(6) = user-jpa(4)+domainlist-jpa(2)
> persistence-file(6) = user-file(2)+mail-file(3)+domainlist-xml(1)
> persistence-jcr(3) = user-jcr(2)+mail-jcr(1)
> persistence-jdbc(7) = user-jdbc(4)+mail-jdbc(3)
> - mail-library(1)
> - domainlist-library(2)
> - user-library(9)
> We could consolidate them into a persistence-library module (from 3 to
> 1 module).
> persistence-library(12) =
> mail-library(1)+domainlist-library(2)+user-library(9)
> - queue-library(2)
> - queue-jms(5)
> We could merge queue-library to queue-jms (a library module makes
> sense when we do something useful.. if it is trivial stuff it can be
> duplicated or moved to the api layer).
> queue-jms(7) = queue-jms(5)+queue-library(2)
> -
> It seems there is agreement on the merging. We still have to decide whether
> to name the modules "persistence-${type}" or simply "${type}" (or maybe
> "data-${type}")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Created: (MAILETSTANDARD-6) Move "genericized" matchers from server codebase
Move "genericized" matchers from server codebase Key: MAILETSTANDARD-6 URL: https://issues.apache.org/jira/browse/MAILETSTANDARD-6 Project: JAMES Standard Mailets Issue Type: Task Affects Versions: 1.0 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Fix For: 1.0 We have at least a bunch of matchers depending on JakartaORO and moved to java.regex that are now "generic" and can be moved here. More will come by evolving mailet api. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Assigned: (JAMES-1067) Remove dependency on commons-oro
[ https://issues.apache.org/jira/browse/JAMES-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara reassigned JAMES-1067: -- Assignee: Stefano Bagnara > Remove dependency on commons-oro > > > Key: JAMES-1067 > URL: https://issues.apache.org/jira/browse/JAMES-1067 > Project: JAMES Server > Issue Type: Task >Reporter: Norman Maurer >Assignee: Stefano Bagnara > Fix For: 3.0 > > > We have a few classes which use commons oro. The dependency should get > removed because commons oro was moved to the attic. > See: > http://jakarta.apache.org/site/news/news-2010-q3.html#20100901.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-1184) Modules consolidation
[
https://issues.apache.org/jira/browse/JAMES-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980642#action_12980642
]
Stefano Bagnara commented on JAMES-1184:
What about the library module?
I was proposing "persistence-library" or "data-library" because here we don't
have $type.
So,
---
- data-library
- file
- jdbc
- jcr
- jpa
---
I have mixed feelings: I like short names but on the other side I don't like
the fact that the 4 modules don't have some prefix/postfix allowing me to
understand they are alternative implementations.
I will wait some day to see if we find better ideas, otherwise proceed with
this plan.
> Modules consolidation
> -
>
> Key: JAMES-1184
> URL: https://issues.apache.org/jira/browse/JAMES-1184
> Project: JAMES Server
> Issue Type: Task
> Components: Build System
>Affects Versions: 3.0-M2
>Reporter: Stefano Bagnara
>Assignee: Stefano Bagnara
> Fix For: 3.0-M3
>
>
> Just opening it to keep track of the proposal to the mailing list.
>
> - mail-file(3)
> - mail-jcr(1)
> - mail-jdbc(3)
> - user-jpa(4)
> - user-file(2)
> - user-jcr(2)
> - user-jdbc(4)
> - domainlist-jpa(2)
> - domainlist-xml(1)
> I only see benefits and no drawbacks in consolidating the 9 modules
> above to the following 4 modules:
> persistence-jpa(6) = user-jpa(4)+domainlist-jpa(2)
> persistence-file(6) = user-file(2)+mail-file(3)+domainlist-xml(1)
> persistence-jcr(3) = user-jcr(2)+mail-jcr(1)
> persistence-jdbc(7) = user-jdbc(4)+mail-jdbc(3)
> - mail-library(1)
> - domainlist-library(2)
> - user-library(9)
> We could consolidate them into a persistence-library module (from 3 to
> 1 module).
> persistence-library(12) =
> mail-library(1)+domainlist-library(2)+user-library(9)
> - queue-library(2)
> - queue-jms(5)
> We could merge queue-library to queue-jms (a library module makes
> sense when we do something useful.. if it is trivial stuff it can be
> duplicated or moved to the api layer).
> queue-jms(7) = queue-jms(5)+queue-library(2)
> -
> It seems there is agreement on the merging. We still have to decide whether
> to name the modules "persistence-${type}" or simply "${type}" (or maybe
> "data-${type}")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Created: (JAMES-1184) Modules consolidation
Modules consolidation
-
Key: JAMES-1184
URL: https://issues.apache.org/jira/browse/JAMES-1184
Project: JAMES Server
Issue Type: Task
Components: Build System
Affects Versions: 3.0-M2
Reporter: Stefano Bagnara
Assignee: Stefano Bagnara
Fix For: 3.0-M3
Just opening it to keep track of the proposal to the mailing list.
- mail-file(3)
- mail-jcr(1)
- mail-jdbc(3)
- user-jpa(4)
- user-file(2)
- user-jcr(2)
- user-jdbc(4)
- domainlist-jpa(2)
- domainlist-xml(1)
I only see benefits and no drawbacks in consolidating the 9 modules
above to the following 4 modules:
persistence-jpa(6) = user-jpa(4)+domainlist-jpa(2)
persistence-file(6) = user-file(2)+mail-file(3)+domainlist-xml(1)
persistence-jcr(3) = user-jcr(2)+mail-jcr(1)
persistence-jdbc(7) = user-jdbc(4)+mail-jdbc(3)
- mail-library(1)
- domainlist-library(2)
- user-library(9)
We could consolidate them into a persistence-library module (from 3 to
1 module).
persistence-library(12) =
mail-library(1)+domainlist-library(2)+user-library(9)
- queue-library(2)
- queue-jms(5)
We could merge queue-library to queue-jms (a library module makes
sense when we do something useful.. if it is trivial stuff it can be
duplicated or moved to the api layer).
queue-jms(7) = queue-jms(5)+queue-library(2)
-
It seems there is agreement on the merging. We still have to decide whether to
name the modules "persistence-${type}" or simply "${type}" (or maybe
"data-${type}")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-1067) Remove dependency on commons-oro
[ https://issues.apache.org/jira/browse/JAMES-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980260#action_12980260 ] Stefano Bagnara commented on JAMES-1067: >From the ML: -- We still have 15 classes depending on the legendary oro regex library. util) util/XMLResources util) util/TimeConverter util) util/sql/SqlResources user-library) vut/lib/VirtualUserTableUtil user-library) vut/lib/AbstractVirtualUserTable mail-file) mailrepository/file/MBoxMailRepository mailets) transport/matchers/SenderIsRegex mailets) transport/matchers/RecipientIsRegex mailets) transport/matchers/NESSpamCheck mailets) transport/matchers/HasMailAttributeWithValueRegex mailets) transport/matchers/GenericRegexMatcher mailets) transport/matchers/FileRegexMatcher mailets) transport/mailets/RemoteDelivery mailets) transport/mailets/DSNBounce mailets) transport/mailets/AbstractVirtualUserTable [...] There may be minor incompatibilities between oro and java.regex matching, but I guess it is better to switch now that we are in milestone and fix the incompatibilities when we find them. All of the matchers can then be moved to mailet-standard project as they don't have special dependencies anymore (this is not true for the mailets). > Remove dependency on commons-oro > > > Key: JAMES-1067 > URL: https://issues.apache.org/jira/browse/JAMES-1067 > Project: JAMES Server > Issue Type: Task >Reporter: Norman Maurer > Fix For: 3.0 > > > We have a few classes which use commons oro. The dependency should get > removed because commons oro was moved to the attic. > See: > http://jakarta.apache.org/site/news/news-2010-q3.html#20100901.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (JAMES-1181) Modules dependencies review
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara resolved JAMES-1181. Resolution: Fixed Fix Version/s: 3.0-M3 Assignee: Stefano Bagnara > Modules dependencies review > --- > > Key: JAMES-1181 > URL: https://issues.apache.org/jira/browse/JAMES-1181 > Project: JAMES Server > Issue Type: Task > Components: Build System >Affects Versions: 3.0-M2 >Reporter: Stefano Bagnara >Assignee: Stefano Bagnara >Priority: Minor > Fix For: 3.0-M3 > > Attachments: graph-server-check.gif, graph-server-edited.gif > > > Just opening an issue because it's simpler to share the image. This can even > be closed as won't fix or resolved. > I found some time to checkout and take some review the current trunk, > starting from modules dependencies. > I have to say the code seems better organized than some months ago, but the > layers increased. This is not necessarily bad, but I think it worth noticing > this. > On past we simply had 3 layers (api, library, function) with clear dependency > scheme: libraries depending only on api, api having no dependencies, > functions depending on api or libraries. > Now I tried to create an updated scheme and things are a bit more complicated > now. > E.g: > util depends on dnsservice-api > core depends on util > mailetcontainer-library depends on core > So in this case between library and api we have 2 more layers. > I didn't investigate on the real classes creating this dependencies issues, > so I don't know how feasible is to fix this "layering" and if it worth or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JDKIM-7) Check escaping behaviour of dns retrieved TXT records (changed from dnsjava 2.0.6 to 2.0.7)
[ https://issues.apache.org/jira/browse/JDKIM-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980074#action_12980074 ] Stefano Bagnara commented on JDKIM-7: - Just to add some external "proof" that the published record is bad: http://dkimcore.org/c/keycheck?selector=pmta&domain=myspace.com from the result page: "This is not a good DKIM key record. You should fix the errors shown in red." Key type: k='rsa\' * The only valid value for the k= field is 'rsa' > Check escaping behaviour of dns retrieved TXT records (changed from dnsjava > 2.0.6 to 2.0.7) > --- > > Key: JDKIM-7 > URL: https://issues.apache.org/jira/browse/JDKIM-7 > Project: JAMES jDKIM > Issue Type: Bug >Reporter: Stefano Bagnara >Assignee: Stefano Bagnara > > Changelog for dnsjava 2.0.7 includes something about escaping of chars in TXT > records. > As we had a workaround in the code maybe it should be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JDKIM-7) Check escaping behaviour of dns retrieved TXT records (changed from dnsjava 2.0.6 to 2.0.7)
[ https://issues.apache.org/jira/browse/JDKIM-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980057#action_12980057 ] Stefano Bagnara commented on JDKIM-7: - Please note that DKIM is an enabling feature: failing to verify a signature should be treated as a missing signature not something negative. So I see no point in being "resilient" to errors. If myspace wants to take advantage from signature verification they will take the time to fix their record. Otherwise they will simply waste time by signing stuff that won't be verified ;-) Try to send a message from myspace mail to gmail and you will see that gmail don't like their record too. Who needs to care of this common issue is the record publisher. If libraries author start ignoring the rfc in order to help people that didn't read the RFC then we would create complete caos. What if a future RFC will say that "rsa\" is a very special algorythm that needs to be interpreted in a very specific way? We implement a library and we should implement the RFC without guess or deviation. RFC are there because of this. If the DKIM group thinks a "relaxed" parsing is needed then the place to work is the DKIM group and an update to the RFC to explain how the parsing can be relaxed. As you can see from the page you linked the myspace issue is probably listed as "Inappropriate key algorithm" (I think k is parsed as "rsa\" so invalid algorythm): 0.5% domains. It is not so common, and it takes one second for myspace to fix it if they care of being verified. 15 months ago I wrote about this (it is italian, but you can see the myspace key in red: http://emailmarketingblog.it/blog/2009/10/01/dkim-troppo-complicato-adottarlo) and I sent a message to myspace too (ignored). > Check escaping behaviour of dns retrieved TXT records (changed from dnsjava > 2.0.6 to 2.0.7) > --- > > Key: JDKIM-7 > URL: https://issues.apache.org/jira/browse/JDKIM-7 > Project: JAMES jDKIM > Issue Type: Bug >Reporter: Stefano Bagnara >Assignee: Stefano Bagnara > > Changelog for dnsjava 2.0.7 includes something about escaping of chars in TXT > records. > As we had a workaround in the code maybe it should be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980052#action_12980052 ] Stefano Bagnara commented on JAMES-1181: No api to api dependencies, too. "util" is special because it is not an api but works like api: does not have any api dependency and libraries can depend on it. (so it is like an api module, but with a different name because in fact it does not represent an api). Of course the guidelines can be worked around in various ways by simply moving modules to their own projects, but I think this make sense. If we find we need more than 3 layers in james-server then we should either find a way to simplify it or move some modules subtree to a separate project (like we did with protocols, with imap, with the mailet-apis). PS: sorry if I repeat this, but in past we had community issues because people thought I was pushing too much "my way"/"my style". I simply explain what I would do. I explain why and I fight when I think the alternatives are wrong, but we are a community and my main rule is power to people that do things (so Eric and Norman in this case! I will try to convince you, but I will be happy also when you disagree and also when we have code I don't like. It is better to have code I don't like than not having code at all, or not having a community) PS2: and thanks to Robert too because I took this "layering" rule from him and after fighting the rule (the restrictions!!) for a while I embraced it. > Modules dependencies review > --- > > Key: JAMES-1181 > URL: https://issues.apache.org/jira/browse/JAMES-1181 > Project: JAMES Server > Issue Type: Task > Components: Build System >Affects Versions: 3.0-M2 >Reporter: Stefano Bagnara >Priority: Minor > Attachments: graph-server-check.gif, graph-server-edited.gif > > > Just opening an issue because it's simpler to share the image. This can even > be closed as won't fix or resolved. > I found some time to checkout and take some review the current trunk, > starting from modules dependencies. > I have to say the code seems better organized than some months ago, but the > layers increased. This is not necessarily bad, but I think it worth noticing > this. > On past we simply had 3 layers (api, library, function) with clear dependency > scheme: libraries depending only on api, api having no dependencies, > functions depending on api or libraries. > Now I tried to create an updated scheme and things are a bit more complicated > now. > E.g: > util depends on dnsservice-api > core depends on util > mailetcontainer-library depends on core > So in this case between library and api we have 2 more layers. > I didn't investigate on the real classes creating this dependencies issues, > so I don't know how feasible is to fix this "layering" and if it worth or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JDKIM-7) Check escaping behaviour of dns retrieved TXT records (changed from dnsjava 2.0.6 to 2.0.7)
[ https://issues.apache.org/jira/browse/JDKIM-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980040#action_12980040 ] Stefano Bagnara commented on JDKIM-7: - Well, of course the myspace record is wrong: host -t txt pmta._domainkey.myspace.com pmta._domainkey.myspace.com descriptive text "k=rsa\\\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQChRebhcm4h8BkIYHRxg1GlKLsDkwdrqkFJ8f88xHQ5Gf3NH4I4e06M3XQ+B4tWWK/rX0srwXFgrJPzKZK+x7gN89nmqyM+NNaM+Wm2C0GjTpx6639zK3bAAGYCm0L9lGD7PgDxpWok+YogH0Ml4acEwDw/cnhErAWAnX8doPliawIDAQAB" - The ; is wrongly excaped twice. > Check escaping behaviour of dns retrieved TXT records (changed from dnsjava > 2.0.6 to 2.0.7) > --- > > Key: JDKIM-7 > URL: https://issues.apache.org/jira/browse/JDKIM-7 > Project: JAMES jDKIM > Issue Type: Bug >Reporter: Stefano Bagnara >Assignee: Stefano Bagnara > > Changelog for dnsjava 2.0.7 includes something about escaping of chars in TXT > records. > As we had a workaround in the code maybe it should be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980037#action_12980037 ] Stefano Bagnara commented on JAMES-1181: In my opinion it worth keeping the dependency layers as few as possible and be "rigorous" about dependencies, of course others may disagree with this. That said, core have api dependencies, so it is a library. A library should not depend on another library (otherwise we have 2 libraries layers and I think we should avoid it). We don't have alternative implementations: we should organize code we have, not code we could have. This will help people understand what we have and how to put their hands in. I can find plenty of classes in the green modules (functions) that we may reuse in future and that could become part of a library, but we don't need this now and following the simple reasoning "it could be used by another implementation" will bring us to a module-per-class pattern. So, as long as we don't have another mailetcontainer implementation I don't care of this issue (again, this is just my opinion and I count for 1 ;-) ): I would even move mailetcontainer-library code to the mailetcontainer-camel package (as it is the only user I don't see advantages in keeping modules separated: too many modules is not good, too). My rule to keep things in order is: api: they does not include implementation details, they do not have dependencies (or at most they have very common dependencies like mailet-api, javamail, commons-logging). library: they only depends on apis or external jars. They don't depend on other internal libraries. These libraries should be shared by functions (no need to have a library when it is used only by a function) functions: everything else. It is harder to see a case of "direct" reuse of a function jar. Most times we'll only have code reuse. I would prefer to limit function to function dependencies (i prefer to merge them instead). We already have a lot of modules, I think we should try to control their grow and the number. Whenever there is no good motivation to have a module we should not create it. OK, now I explained my way of thinking, If I didn't convince you that it worth then I will move back the JamesMailetContext and recreate the library-library dependency between mailetcontainer-library and core. > Modules dependencies review > --- > > Key: JAMES-1181 > URL: https://issues.apache.org/jira/browse/JAMES-1181 > Project: JAMES Server > Issue Type: Task > Components: Build System >Affects Versions: 3.0-M2 >Reporter: Stefano Bagnara >Priority: Minor > Attachments: graph-server-check.gif, graph-server-edited.gif > > > Just opening an issue because it's simpler to share the image. This can even > be closed as won't fix or resolved. > I found some time to checkout and take some review the current trunk, > starting from modules dependencies. > I have to say the code seems better organized than some months ago, but the > layers increased. This is not necessarily bad, but I think it worth noticing > this. > On past we simply had 3 layers (api, library, function) with clear dependency > scheme: libraries depending only on api, api having no dependencies, > functions depending on api or libraries. > Now I tried to create an updated scheme and things are a bit more complicated > now. > E.g: > util depends on dnsservice-api > core depends on util > mailetcontainer-library depends on core > So in this case between library and api we have 2 more layers. > I didn't investigate on the real classes creating this dependencies issues, > so I don't know how feasible is to fix this "layering" and if it worth or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JDKIM-7) Check escaping behaviour of dns retrieved TXT records (changed from dnsjava 2.0.6 to 2.0.7)
[ https://issues.apache.org/jira/browse/JDKIM-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980021#action_12980021 ] Stefano Bagnara commented on JDKIM-7: - I use jDKIM in production since months and never had problems with escaping with new dnsjava. Can you provide a test case? > Check escaping behaviour of dns retrieved TXT records (changed from dnsjava > 2.0.6 to 2.0.7) > --- > > Key: JDKIM-7 > URL: https://issues.apache.org/jira/browse/JDKIM-7 > Project: JAMES jDKIM > Issue Type: Bug >Reporter: Stefano Bagnara >Assignee: Stefano Bagnara > > Changelog for dnsjava 2.0.7 includes something about escaping of chars in TXT > records. > As we had a workaround in the code maybe it should be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Updated: (JAMES-1181) Modules dependencies review
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara updated JAMES-1181: --- Attachment: graph-server-edited.gif > Modules dependencies review > --- > > Key: JAMES-1181 > URL: https://issues.apache.org/jira/browse/JAMES-1181 > Project: JAMES Server > Issue Type: Task > Components: Build System >Affects Versions: 3.0-M2 >Reporter: Stefano Bagnara >Priority: Minor > Attachments: graph-server-check.gif, graph-server-edited.gif > > > Just opening an issue because it's simpler to share the image. This can even > be closed as won't fix or resolved. > I found some time to checkout and take some review the current trunk, > starting from modules dependencies. > I have to say the code seems better organized than some months ago, but the > layers increased. This is not necessarily bad, but I think it worth noticing > this. > On past we simply had 3 layers (api, library, function) with clear dependency > scheme: libraries depending only on api, api having no dependencies, > functions depending on api or libraries. > Now I tried to create an updated scheme and things are a bit more complicated > now. > E.g: > util depends on dnsservice-api > core depends on util > mailetcontainer-library depends on core > So in this case between library and api we have 2 more layers. > I didn't investigate on the real classes creating this dependencies issues, > so I don't know how feasible is to fix this "layering" and if it worth or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979636#action_12979636 ] Stefano Bagnara commented on JAMES-1181: I did the dnsservice-library stuff. I had also to move JamesMailetContext from mailetcontainer-library to mailetcontainer-camel in order to fix the "library-library" dependency issue. Now the dependency tree is more appealing. About renaming nio-netty to nio-library I've had a look at the content and I see there is a lot of jmx stuff an just 2 nio classes: I'm not sure what's the best name for this library so I leave it as is. Maybe "service-library" would be better as it contains stuff used by tcp services, but "service-library" is a really generic name, too similar to dnsservice-library.. so I don't have a better name for it right now. > Modules dependencies review > --- > > Key: JAMES-1181 > URL: https://issues.apache.org/jira/browse/JAMES-1181 > Project: JAMES Server > Issue Type: Task > Components: Build System >Affects Versions: 3.0-M2 >Reporter: Stefano Bagnara >Priority: Minor > Attachments: graph-server-check.gif, graph-server-edited.gif > > > Just opening an issue because it's simpler to share the image. This can even > be closed as won't fix or resolved. > I found some time to checkout and take some review the current trunk, > starting from modules dependencies. > I have to say the code seems better organized than some months ago, but the > layers increased. This is not necessarily bad, but I think it worth noticing > this. > On past we simply had 3 layers (api, library, function) with clear dependency > scheme: libraries depending only on api, api having no dependencies, > functions depending on api or libraries. > Now I tried to create an updated scheme and things are a bit more complicated > now. > E.g: > util depends on dnsservice-api > core depends on util > mailetcontainer-library depends on core > So in this case between library and api we have 2 more layers. > I didn't investigate on the real classes creating this dependencies issues, > so I don't know how feasible is to fix this "layering" and if it worth or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979524#action_12979524 ] Stefano Bagnara commented on JAMES-1181: I create the graph using a very raw bytecode dependency analyzer I written some years ago (it doesn't even support java5 stuff) and then I render the graph using yEd. I would contribute my stuff to the project but it is really unusable by anyone but me and I have no time to make it better. I agree with your concerns about core becoming the catch-all module, but I don't see a better placement and I think it is better to have some bloat in core than having one more layer in the dependency tree. My main concern is not with the layer itself, but the fact that an "util" package depends on "api": api and utils by definitions should not have internal dependencies. Also "util" is not a better catch-all than "core", don't you think? The netmatcher stuff is used by mailet and smtpserver. They only share core and queue-api as dependencies. So the 4 solutions I see for this are: 1- create a dnsservice-library as a new home for netmatcher/inetnetwork 2- use core and delay the split to module to the future if the dns related functions will grow 3- use dnsservice-api as the new home for netmatcher/inetnetwork (they are not directly api stuff but they depends on dnsservice, so this is anyway a better place) 4- move the network matching methods to dnsservice interface and then have the netmatcher+inetnetwork code moved between dnsservice-api and dnsservice-dnsjava. mailet and smtpserver would then depend on dnsservice-api only and at runtime to the dnsservice-dnsjava component. I like all of them more than keeping them in "util". 4 is more complex than 1..3, so I would probably go for one in 1..3 and simply remember that we have 4 as possible improvement. PS: I don't want to force "refactorings" as I don't have your same knowledge of the current code, so if you still think that leaving code where it is now is better I'll accept it :-) Otherwise let me know if you like some of the proposed changes and I'll try to find the time to apply them while I take some more confidence with the updated trunk. > Modules dependencies review > --- > > Key: JAMES-1181 > URL: https://issues.apache.org/jira/browse/JAMES-1181 > Project: JAMES Server > Issue Type: Task > Components: Build System >Affects Versions: 3.0-M2 >Reporter: Stefano Bagnara >Priority: Minor > Attachments: graph-server-check.gif > > > Just opening an issue because it's simpler to share the image. This can even > be closed as won't fix or resolved. > I found some time to checkout and take some review the current trunk, > starting from modules dependencies. > I have to say the code seems better organized than some months ago, but the > layers increased. This is not necessarily bad, but I think it worth noticing > this. > On past we simply had 3 layers (api, library, function) with clear dependency > scheme: libraries depending only on api, api having no dependencies, > functions depending on api or libraries. > Now I tried to create an updated scheme and things are a bit more complicated > now. > E.g: > util depends on dnsservice-api > core depends on util > mailetcontainer-library depends on core > So in this case between library and api we have 2 more layers. > I didn't investigate on the real classes creating this dependencies issues, > so I don't know how feasible is to fix this "layering" and if it worth or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-1181) Modules dependencies review
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979428#action_12979428 ] Stefano Bagnara commented on JAMES-1181: Also: 1) nio-netty and repository-file seems to have a "library" role from the schema: what about postfixing them with library? 2) the util -> dnsservice-api dependencies seems to be caused by the util.netmatcher package (and the "private" util.inetnetwork package). It seems this stuff could be safely moved to the "core" module removing one full layer (and having all of the "api" modules + "util" in a single layer with no dependencies). > Modules dependencies review > --- > > Key: JAMES-1181 > URL: https://issues.apache.org/jira/browse/JAMES-1181 > Project: JAMES Server > Issue Type: Task > Components: Build System >Affects Versions: 3.0-M2 >Reporter: Stefano Bagnara >Priority: Minor > Attachments: graph-server-check.gif > > > Just opening an issue because it's simpler to share the image. This can even > be closed as won't fix or resolved. > I found some time to checkout and take some review the current trunk, > starting from modules dependencies. > I have to say the code seems better organized than some months ago, but the > layers increased. This is not necessarily bad, but I think it worth noticing > this. > On past we simply had 3 layers (api, library, function) with clear dependency > scheme: libraries depending only on api, api having no dependencies, > functions depending on api or libraries. > Now I tried to create an updated scheme and things are a bit more complicated > now. > E.g: > util depends on dnsservice-api > core depends on util > mailetcontainer-library depends on core > So in this case between library and api we have 2 more layers. > I didn't investigate on the real classes creating this dependencies issues, > so I don't know how feasible is to fix this "layering" and if it worth or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Updated: (JAMES-1181) Modules dependencies review
[ https://issues.apache.org/jira/browse/JAMES-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara updated JAMES-1181: --- Attachment: graph-server-check.gif > Modules dependencies review > --- > > Key: JAMES-1181 > URL: https://issues.apache.org/jira/browse/JAMES-1181 > Project: JAMES Server > Issue Type: Task > Components: Build System >Affects Versions: 3.0-M2 >Reporter: Stefano Bagnara >Priority: Minor > Attachments: graph-server-check.gif > > > Just opening an issue because it's simpler to share the image. This can even > be closed as won't fix or resolved. > I found some time to checkout and take some review the current trunk, > starting from modules dependencies. > I have to say the code seems better organized than some months ago, but the > layers increased. This is not necessarily bad, but I think it worth noticing > this. > On past we simply had 3 layers (api, library, function) with clear dependency > scheme: libraries depending only on api, api having no dependencies, > functions depending on api or libraries. > Now I tried to create an updated scheme and things are a bit more complicated > now. > E.g: > util depends on dnsservice-api > core depends on util > mailetcontainer-library depends on core > So in this case between library and api we have 2 more layers. > I didn't investigate on the real classes creating this dependencies issues, > so I don't know how feasible is to fix this "layering" and if it worth or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Created: (JAMES-1181) Modules dependencies review
Modules dependencies review --- Key: JAMES-1181 URL: https://issues.apache.org/jira/browse/JAMES-1181 Project: JAMES Server Issue Type: Task Components: Build System Affects Versions: 3.0-M2 Reporter: Stefano Bagnara Priority: Minor Just opening an issue because it's simpler to share the image. This can even be closed as won't fix or resolved. I found some time to checkout and take some review the current trunk, starting from modules dependencies. I have to say the code seems better organized than some months ago, but the layers increased. This is not necessarily bad, but I think it worth noticing this. On past we simply had 3 layers (api, library, function) with clear dependency scheme: libraries depending only on api, api having no dependencies, functions depending on api or libraries. Now I tried to create an updated scheme and things are a bit more complicated now. E.g: util depends on dnsservice-api core depends on util mailetcontainer-library depends on core So in this case between library and api we have 2 more layers. I didn't investigate on the real classes creating this dependencies issues, so I don't know how feasible is to fix this "layering" and if it worth or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Created: (PROTOCOLS-12) Retr/Top commands are blocking
Retr/Top commands are blocking -- Key: PROTOCOLS-12 URL: https://issues.apache.org/jira/browse/PROTOCOLS-12 Project: JAMES Protocols Issue Type: Bug Components: pop3 Affects Versions: 1.1 Reporter: Stefano Bagnara Assignee: Norman Maurer As I was writing in #PROTOCOLS-11 AbstractRetrCmdHandler.writeMessageContentTo does a loop and blocks while it writes each line of the message to the output channel. This way if the remote client is blocking you either fill a buffer or block an executor thread of the SEDA pool. So it has to be changed. In the API we solved this issue for incoming streams (DataCmdHandler for SMTP) and we push a new linehandler in the chain to handle asynchronous streaming. Maybe this needs a similar solution but reversed for writing a stream. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (PROTOCOLS-11) Make CommandHandler/LineHandler/ConnectHandler more consistent
[ https://issues.apache.org/jira/browse/PROTOCOLS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934121#action_12934121 ] Stefano Bagnara commented on PROTOCOLS-11: -- Well, the issue is that Retr and Top command handlers are wrong :-) They are blocking: AbstractRetrCmdHandler.writeMessageContentTo does a loop and blocks while it writes each line of the message to the output channel. This way if the remote client is blocking you either fill a buffer or block an executor thread of the SEDA pool. So it has to be changed. In the API we solved this issue for incoming streams (DataCmdHandler for SMTP) and we push a new linehandler in the chain to handle asynchronous streaming. Maybe this needs a similar solution but reversed for writing a stream. I'm opening a new JIRA for this purpose. > Make CommandHandler/LineHandler/ConnectHandler more consistent > -- > > Key: PROTOCOLS-11 > URL: https://issues.apache.org/jira/browse/PROTOCOLS-11 > Project: JAMES Protocols > Issue Type: Task >Affects Versions: 1.0, 1.1 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 1.2-M2 > > > At the moment we have three different Handler types. These are > ConnectHandler, CommandHandler and LineHandler. The ConnectHandler and > LineHandler use void as return type and so if you want to write something > back to the client you use Session.write(...). On the other hand if you use > CommandHandler you can use the return type of Response to trigger a write > back to the client and Session.write(..). We should only use > Session.write(...) in all cases -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (IMAP-230) Remove usage of RewindableInputStream
[ https://issues.apache.org/jira/browse/IMAP-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933342#action_12933342 ] Stefano Bagnara commented on IMAP-230: -- A RewindableInputStream can be consumed multiple times. If you need to share the stream then you need it to be al least rewindable. Bettwe way would be the SharedInputStream (the logic is always having multiple "not aligned" consumers of the same stream). Don't know if this is still needed or not. > Remove usage of RewindableInputStream > - > > Key: IMAP-230 > URL: https://issues.apache.org/jira/browse/IMAP-230 > Project: JAMES Imap > Issue Type: Task >Affects Versions: 0.1, 0.2-M1 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 0.2 > > > When accessing the Message content we use a custom InputStream called > RewindableInputStream. I don't know why I thought this makes much sense in > the past... We should just use a normal InputStream -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (PROTOCOLS-11) Make CommandHandler/LineHandler/ConnectHandler more consistent
[ https://issues.apache.org/jira/browse/PROTOCOLS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933341#action_12933341 ] Stefano Bagnara commented on PROTOCOLS-11: -- We made this way to make it simpler to write CommandHandler. The simplicity could not be ported to Connect/LIne handler because they are more powerful, but the CommandHandler pattern is simpler to implement correctly: implementors are "forced" by the interface to do the right thing. In SMTP/POP3 there are no commands that do not return, and they always returns one result in response to one command. > Make CommandHandler/LineHandler/ConnectHandler more consistent > -- > > Key: PROTOCOLS-11 > URL: https://issues.apache.org/jira/browse/PROTOCOLS-11 > Project: JAMES Protocols > Issue Type: Task >Affects Versions: 1.0, 1.1 >Reporter: Norman Maurer >Assignee: Norman Maurer > Fix For: 1.2-M2 > > > At the moment we have three different Handler types. These are > ConnectHandler, CommandHandler and LineHandler. The ConnectHandler and > LineHandler use void as return type and so if you want to write something > back to the client you use Session.write(...). On the other hand if you use > CommandHandler you can use the return type of Response to trigger a write > back to the client and Session.write(..). We should only use > Session.write(...) in all cases -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-900) NullPointerException during local delivery spooling
[ https://issues.apache.org/jira/browse/JAMES-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12925734#action_12925734 ] Stefano Bagnara commented on JAMES-900: --- Never happened to me. Maybe you are using dbfile as spool repositories, and they are not supported to do that (IIRC using dbfile in spool repositories led to NPE). > NullPointerException during local delivery spooling > --- > > Key: JAMES-900 > URL: https://issues.apache.org/jira/browse/JAMES-900 > Project: JAMES Server > Issue Type: Bug > Components: SpoolManager & Processors >Affects Versions: 2.3.1 > Environment: Windows XP, Sun JDK 1.6.0_12, MySQL 5.0 backend >Reporter: Amichai Rothman > Fix For: 3.0-M2 > > > The exception below occurs 1-2 times a day on a server handling between a few > hundred and a few thousands of messages per day. > I took a short look at the code, and it looks like there's a > MimeMessageCopyOnWriteProxy wrapping a null message. A few possible causes: > - MessageReferenceTracker.getWrapped() should be synchronized, as the field > is neither final nor volatile and so it's possible that a thread other than > the one which creates it will see a null wrapped message. > - the refCount field is not properly synchronized nor volatile so methods > which set/replace its value (private constructor, > getWrappedMessageForWriting) may cause some threads to see the new instance > and some the old one. this can result in buggy reference counting, which can > result in the wrapped message being set to null (when reference count is > decreased too much) and then being accessed. > - a MailImpl is being constructed (or copy-constructed) somewhere with a null > message (which is passed on to the proxy class). > - something completely different. > The stacktrace from spoolmanager log: > 25/04/09 02:00:58 ERROR spoolmanager.transport: Exception calling > LocalDelivery: Exception spooling message: Exception caught while storing > mail Container: > javax.mail.MessagingException: Exception spooling message: Exception caught > while storing mail Container: ; > nested exception is: > javax.mail.MessagingException: Exception caught while storing mail > Container: ; > nested exception is: > java.lang.NullPointerException > at org.apache.james.James.sendMail(James.java:501) > at org.apache.james.James.sendMail(James.java:454) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > org.apache.avalon.phoenix.components.application.BlockInvocationHandler.invoke(BlockInvocationHandler.java:134) > at $Proxy9.sendMail(Unknown Source) > at > org.apache.james.transport.mailets.ToMultiRepository.service(ToMultiRepository.java:183) > at > org.apache.james.transport.mailets.LocalDelivery.service(LocalDelivery.java:66) > at > org.apache.james.transport.LinearProcessor.service(LinearProcessor.java:424) > at > org.apache.james.transport.JamesSpoolManager.process(JamesSpoolManager.java:405) > at > org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:309) > at java.lang.Thread.run(Unknown Source) > Caused by: javax.mail.MessagingException: Exception caught while storing mail > Container: ; > nested exception is: > java.lang.NullPointerException > at > org.apache.james.mailrepository.JDBCMailRepository.store(JDBCMailRepository.java:764) > at > org.apache.james.mailrepository.JDBCSpoolRepository.store(JDBCSpoolRepository.java:240) > at > org.apache.james.mailrepository.MailStoreSpoolRepository.store(MailStoreSpoolRepository.java:126) > at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > org.apache.avalon.phoenix.components.application.BlockInvocationHandler.invoke(BlockInvocationHandler.java:134) > at $Proxy5.store(Unknown Source) > at org.apache.james.James.sendMail(James.java:493) > ... 13 more > Caused by: java.lang.NullPointerException > at > org.apache.james.core.MimeMessageUtil.calculateMessageSize(MimeMessageUtil.java:277) > at > org.apache.james.core.MimeMessageUtil.getMessageSize(MimeMessageUtil.java:261) > at > org.apache.james.core.MimeMessageCopyOnWriteProxy.getMessageSize(MimeMessageCopyOnWriteProxy.java:745) > at > org.apache.james.core.MimeMessageUtil.getMessageSize(MimeMessageUtil.java:257) > at org.apache.james.core.MailImpl.getMessag
[jira] Resolved: (JDKIM-24) Add DKIMVerify mailet
[ https://issues.apache.org/jira/browse/JDKIM-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara resolved JDKIM-24. -- Resolution: Fixed Done. Maybe we should also add some more mail attributes in addition to the current text. > Add DKIMVerify mailet > - > > Key: JDKIM-24 > URL: https://issues.apache.org/jira/browse/JDKIM-24 > Project: JAMES jDKIM > Issue Type: New Feature > Components: mailet >Affects Versions: 0.2 >Reporter: Stefano Bagnara >Assignee: Stefano Bagnara > Fix For: 0.2 > > > We only provide signing mailets right now. > DKIMVerify is a must have, too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (JDKIM-23) Add 2 stage verification process
[ https://issues.apache.org/jira/browse/JDKIM-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara resolved JDKIM-23. -- Resolution: Fixed > Add 2 stage verification process > > > Key: JDKIM-23 > URL: https://issues.apache.org/jira/browse/JDKIM-23 > Project: JAMES jDKIM > Issue Type: Improvement > Components: library >Affects Versions: 0.2 >Reporter: Stefano Bagnara >Assignee: Stefano Bagnara > Fix For: 0.2 > > > As for the signing process we should expose internal methods to support > multiple key verification for users parsing their messages and providing an > outputstream for the body. > This will make it simpler to write a DKIMVerify mailet based on Javamail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Created: (JDKIM-24) Add DKIMVerify mailet
Add DKIMVerify mailet - Key: JDKIM-24 URL: https://issues.apache.org/jira/browse/JDKIM-24 Project: JAMES jDKIM Issue Type: New Feature Components: mailet Affects Versions: 0.2 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Fix For: 0.2 We only provide signing mailets right now. DKIMVerify is a must have, too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Created: (JDKIM-23) Add 2 stage verification process
Add 2 stage verification process Key: JDKIM-23 URL: https://issues.apache.org/jira/browse/JDKIM-23 Project: JAMES jDKIM Issue Type: Improvement Components: library Affects Versions: 0.2 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Fix For: 0.2 As for the signing process we should expose internal methods to support multiple key verification for users parsing their messages and providing an outputstream for the body. This will make it simpler to write a DKIMVerify mailet based on Javamail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (JDKIM-22) No signature should not throw PermFail
[ https://issues.apache.org/jira/browse/JDKIM-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara resolved JDKIM-22. -- Resolution: Fixed This break backward compatibility, but we are in 0.2, I think it worth to be more correct than backward compatible. > No signature should not throw PermFail > -- > > Key: JDKIM-22 > URL: https://issues.apache.org/jira/browse/JDKIM-22 > Project: JAMES jDKIM > Issue Type: Bug > Components: library >Affects Versions: 0.2 >Reporter: Stefano Bagnara >Assignee: Stefano Bagnara > Fix For: 0.2 > > > Currently we throw PermFail unless a valid signature is found. > It would be better to simply return null/empty list when no signature is > found at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Created: (JDKIM-22) No signature should not throw PermFail
No signature should not throw PermFail -- Key: JDKIM-22 URL: https://issues.apache.org/jira/browse/JDKIM-22 Project: JAMES jDKIM Issue Type: Bug Components: library Affects Versions: 0.2 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Fix For: 0.2 Currently we throw PermFail unless a valid signature is found. It would be better to simply return null/empty list when no signature is found at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (JDKIM-21) potential issues?
[ https://issues.apache.org/jira/browse/JDKIM-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara resolved JDKIM-21. -- Fix Version/s: 0.2 Resolution: Fixed > potential issues? > -- > > Key: JDKIM-21 > URL: https://issues.apache.org/jira/browse/JDKIM-21 > Project: JAMES jDKIM > Issue Type: Question > Components: library >Affects Versions: 0.2, 1.0 > Environment: java version "1.6.0_18" ubuntu 10.04 >Reporter: Ben Aldrich >Assignee: Stefano Bagnara >Priority: Minor > Fix For: 0.2 > > > I ran the jdkim library through find bugs and found a few things. Some things > i thought you might be doing because of backwards compatibility. So here is > the quick list. > DKIMVerifier: > records.size() == 0 instead of records.isEmpty() > fields.size() == 0 instead of fields.isEmpty() > use of hashtable (it's deprecated) > bodyHashJobs.size() == 0 instead of bodyHashJobs.isEmpty() > verifiedSignatures.size() == 0 instead of verifiedSignatures.isEmpty() > DKIMCommon: > done = new Integer(0) instead of Integer.valueOf(0) *I noticed you have a > comment for this already? > DNSPublicKeyRecordRetriever: > use of StringBuffer instead of StringBuilder > SignatureRecordImpl: > use of StringBuffer instead of StringBuilder > TagValue: > use of StringBuffer instead of StringBuilder -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JDKIM-21) potential issues?
[ https://issues.apache.org/jira/browse/JDKIM-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12909830#action_12909830 ] Stefano Bagnara commented on JDKIM-21: -- At the beginning jdkim was java 1.4 compatible. Now we can "improve" that stuff with 1.5 source code. Thank you for reporting! > potential issues? > -- > > Key: JDKIM-21 > URL: https://issues.apache.org/jira/browse/JDKIM-21 > Project: JAMES jDKIM > Issue Type: Question > Components: library >Affects Versions: 0.2, 1.0 > Environment: java version "1.6.0_18" ubuntu 10.04 >Reporter: Ben Aldrich >Assignee: Stefano Bagnara >Priority: Minor > > I ran the jdkim library through find bugs and found a few things. Some things > i thought you might be doing because of backwards compatibility. So here is > the quick list. > DKIMVerifier: > records.size() == 0 instead of records.isEmpty() > fields.size() == 0 instead of fields.isEmpty() > use of hashtable (it's deprecated) > bodyHashJobs.size() == 0 instead of bodyHashJobs.isEmpty() > verifiedSignatures.size() == 0 instead of verifiedSignatures.isEmpty() > DKIMCommon: > done = new Integer(0) instead of Integer.valueOf(0) *I noticed you have a > comment for this already? > DNSPublicKeyRecordRetriever: > use of StringBuffer instead of StringBuilder > SignatureRecordImpl: > use of StringBuffer instead of StringBuilder > TagValue: > use of StringBuffer instead of StringBuilder -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Assigned: (JDKIM-21) potential issues?
[ https://issues.apache.org/jira/browse/JDKIM-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara reassigned JDKIM-21: Assignee: Stefano Bagnara > potential issues? > -- > > Key: JDKIM-21 > URL: https://issues.apache.org/jira/browse/JDKIM-21 > Project: JAMES jDKIM > Issue Type: Question > Components: library >Affects Versions: 0.2, 1.0 > Environment: java version "1.6.0_18" ubuntu 10.04 >Reporter: Ben Aldrich >Assignee: Stefano Bagnara >Priority: Minor > > I ran the jdkim library through find bugs and found a few things. Some things > i thought you might be doing because of backwards compatibility. So here is > the quick list. > DKIMVerifier: > records.size() == 0 instead of records.isEmpty() > fields.size() == 0 instead of fields.isEmpty() > use of hashtable (it's deprecated) > bodyHashJobs.size() == 0 instead of bodyHashJobs.isEmpty() > verifiedSignatures.size() == 0 instead of verifiedSignatures.isEmpty() > DKIMCommon: > done = new Integer(0) instead of Integer.valueOf(0) *I noticed you have a > comment for this already? > DNSPublicKeyRecordRetriever: > use of StringBuffer instead of StringBuilder > SignatureRecordImpl: > use of StringBuffer instead of StringBuilder > TagValue: > use of StringBuffer instead of StringBuilder -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JDKIM-20) jdkim will throw unexpected exceptions
[
https://issues.apache.org/jira/browse/JDKIM-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908969#action_12908969
]
Stefano Bagnara commented on JDKIM-20:
--
I added a catch for the IllegalArgumentException by throwing a PermError with a
meaningful error. Added a sample synthetical message to the test suite (the
issue was with unencoded "=" in the value of "i=" parameter).
Also I verified an IllegalStateException while parsing the remote Public Key. I
added a similar try/catch to the signatureVerify method, as you suggested.
> jdkim will throw unexpected exceptions
> --
>
> Key: JDKIM-20
> URL: https://issues.apache.org/jira/browse/JDKIM-20
> Project: JAMES jDKIM
> Issue Type: Bug
> Components: library
>Affects Versions: 0.2, 1.0
> Environment: java version "1.6.0_18" ubuntu 10.04
>Reporter: Ben Aldrich
>Assignee: Stefano Bagnara
> Fix For: 0.2
>
> Attachments: illegalargumentexception.txt
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> when calling validate I am seeing IllegalStateExceptions and
> IllegalArgumentException.
> It looks like we just need to catch these exceptions in the DKIMVerifier.java
> more specifically, in the verify method we need to add this around line 270 :
> } catch (IllegalArgumentException e) {
> throw new PermFailException(e.getMessage());
> and we should also add this in the signatureVerify method:
> try {
> signature.initVerify(key.getPublicKey());
> } catch (IllegalStateException e) {
> throw new PermFailException(e.getMessage());
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (JDKIM-20) jdkim will throw unexpected exceptions
[
https://issues.apache.org/jira/browse/JDKIM-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefano Bagnara resolved JDKIM-20.
--
Fix Version/s: 0.2
Resolution: Fixed
> jdkim will throw unexpected exceptions
> --
>
> Key: JDKIM-20
> URL: https://issues.apache.org/jira/browse/JDKIM-20
> Project: JAMES jDKIM
> Issue Type: Bug
> Components: library
>Affects Versions: 0.2, 1.0
> Environment: java version "1.6.0_18" ubuntu 10.04
>Reporter: Ben Aldrich
>Assignee: Stefano Bagnara
> Fix For: 0.2
>
> Attachments: illegalargumentexception.txt
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> when calling validate I am seeing IllegalStateExceptions and
> IllegalArgumentException.
> It looks like we just need to catch these exceptions in the DKIMVerifier.java
> more specifically, in the verify method we need to add this around line 270 :
> } catch (IllegalArgumentException e) {
> throw new PermFailException(e.getMessage());
> and we should also add this in the signatureVerify method:
> try {
> signature.initVerify(key.getPublicKey());
> } catch (IllegalStateException e) {
> throw new PermFailException(e.getMessage());
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Assigned: (JDKIM-20) jdkim will throw unexpected exceptions
[
https://issues.apache.org/jira/browse/JDKIM-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefano Bagnara reassigned JDKIM-20:
Assignee: Stefano Bagnara
> jdkim will throw unexpected exceptions
> --
>
> Key: JDKIM-20
> URL: https://issues.apache.org/jira/browse/JDKIM-20
> Project: JAMES jDKIM
> Issue Type: Bug
> Components: library
>Affects Versions: 0.2, 1.0
> Environment: java version "1.6.0_18" ubuntu 10.04
>Reporter: Ben Aldrich
>Assignee: Stefano Bagnara
> Attachments: illegalargumentexception.txt
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> when calling validate I am seeing IllegalStateExceptions and
> IllegalArgumentException.
> It looks like we just need to catch these exceptions in the DKIMVerifier.java
> more specifically, in the verify method we need to add this around line 270 :
> } catch (IllegalArgumentException e) {
> throw new PermFailException(e.getMessage());
> and we should also add this in the signatureVerify method:
> try {
> signature.initVerify(key.getPublicKey());
> } catch (IllegalStateException e) {
> throw new PermFailException(e.getMessage());
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JDKIM-20) jdkim will throw unexpected exceptions
[
https://issues.apache.org/jira/browse/JDKIM-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12908560#action_12908560
]
Stefano Bagnara commented on JDKIM-20:
--
Hi Ben,
thank you for reporting the issue. Can you provide a couple of sample mail so
that I can add them to the test suite as a proof of the bug & bugfix?
Otherwise a full stack trace for the 2 conditions would help understanding what
the "condition" is and how to synthetize a couple of messages to prove that.
Stefano
> jdkim will throw unexpected exceptions
> --
>
> Key: JDKIM-20
> URL: https://issues.apache.org/jira/browse/JDKIM-20
> Project: JAMES jDKIM
> Issue Type: Bug
> Components: library
>Affects Versions: 0.2, 1.0
> Environment: java version "1.6.0_18" ubuntu 10.04
>Reporter: Ben Aldrich
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> when calling validate I am seeing IllegalStateExceptions and
> IllegalArgumentException.
> It looks like we just need to catch these exceptions in the DKIMVerifier.java
> more specifically, in the verify method we need to add this around line 270 :
> } catch (IllegalArgumentException e) {
> throw new PermFailException(e.getMessage());
> and we should also add this in the signatureVerify method:
> try {
> signature.initVerify(key.getPublicKey());
> } catch (IllegalStateException e) {
> throw new PermFailException(e.getMessage());
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (JDKIM-19) Change scope on 2 variables in DKIMSign to support subclassing
[ https://issues.apache.org/jira/browse/JDKIM-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara resolved JDKIM-19. -- Resolution: Fixed > Change scope on 2 variables in DKIMSign to support subclassing > -- > > Key: JDKIM-19 > URL: https://issues.apache.org/jira/browse/JDKIM-19 > Project: JAMES jDKIM > Issue Type: Improvement > Components: mailet >Affects Versions: 0.2 > Environment: software, mailet >Reporter: Jerry Malcolm >Assignee: Stefano Bagnara > Fix For: 0.2 > > > I need to have separate private keys for DKIM for different domains that I > host on my server. I plan to create a database table that looks up the > private key based on the domain. I figured I could subclass your DKIMSign > mailet, override the service method, set the privateKey and > signatureTemplate variables and then call the parent service method. But it > turns out that the privateKey and signatureTemplate variables are scoped to > 'private'. I know I can just clone the entire method or even the entire > java class file. But I'd much prefer to inherit everything other than that > one little change I need. But I can't do it with private scope on the key > and template. > Request to change scope on pfivateKey and signatureTemplate variables from > private to protected to support subclassing of this mailet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JDKIM-19) Change scope on 2 variables in DKIMSign to support subclassing
[ https://issues.apache.org/jira/browse/JDKIM-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901798#action_12901798 ] Stefano Bagnara commented on JDKIM-19: -- I added the 2 protected getters, but please again, make sure your mailets are thread safe if you extend this. If you synchronize the service method then your mailet will run single threaded and this is not good. I don't see a good way to support multidomain by simply overriding the 2 protected methods. > Change scope on 2 variables in DKIMSign to support subclassing > -- > > Key: JDKIM-19 > URL: https://issues.apache.org/jira/browse/JDKIM-19 > Project: JAMES jDKIM > Issue Type: Improvement > Components: mailet >Affects Versions: 0.2 > Environment: software, mailet >Reporter: Jerry Malcolm >Assignee: Stefano Bagnara > Fix For: 0.2 > > > I need to have separate private keys for DKIM for different domains that I > host on my server. I plan to create a database table that looks up the > private key based on the domain. I figured I could subclass your DKIMSign > mailet, override the service method, set the privateKey and > signatureTemplate variables and then call the parent service method. But it > turns out that the privateKey and signatureTemplate variables are scoped to > 'private'. I know I can just clone the entire method or even the entire > java class file. But I'd much prefer to inherit everything other than that > one little change I need. But I can't do it with private scope on the key > and template. > Request to change scope on pfivateKey and signatureTemplate variables from > private to protected to support subclassing of this mailet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (JDKIM-18) jdkim verify(InputStream) doesn't clean up temp files until shutdown
[ https://issues.apache.org/jira/browse/JDKIM-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara resolved JDKIM-18. -- Resolution: Fixed Hi Ben, i preferred to add an explicit dispose instead of relying on "unrelyable" finalizers. Let me know if it works ok now! Thank you for reporting and investigating the issue! Stefano > jdkim verify(InputStream) doesn't clean up temp files until shutdown > > > Key: JDKIM-18 > URL: https://issues.apache.org/jira/browse/JDKIM-18 > Project: JAMES jDKIM > Issue Type: Bug > Components: library >Affects Versions: 0.2 > Environment: Verified this in solaris 10 and ubuntu 10.04 > java 1.6.0_13 >Reporter: Ben Aldrich >Assignee: Stefano Bagnara >Priority: Critical > Fix For: 0.2 > > > When you pass jdkim an input stream like so : > new DKIMVerifier().verify(new ByteArrayInputStream(sb.toString().getBytes())); > the jkdim impl/Message.java creates a mime4j temp file that doesn't get > deleted until the application exits. This causes any system that runs as a > daemon to eventually run out of disk space. > I did a quick test and replaced Message.java with my own implementation using > the regular javax MimeMessage to pull out the headers and the app no longer > creates the temp files. This isn't really a good solution though because now > I can't pass simple canonicalization. I don't know mime4j very well but > digging through the source it only sets the deleteOnExit flag by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JDKIM-19) Change scope on 2 variables in DKIMSign to support subclassing
[ https://issues.apache.org/jira/browse/JDKIM-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901444#action_12901444 ] Stefano Bagnara commented on JDKIM-19: -- please note that simply changing the 2 fields to protect would not allow you to subclass and change the field value based on mail input because mailets must be thread safe so fields must not be changed by service executions. I guess the best solution is to create 2 protected methods (getPrivateKey and getSignatureTemplate) that by default will lookup the private fields and in your subclass you can replace their implementation to lookup a db instead of using a private field). > Change scope on 2 variables in DKIMSign to support subclassing > -- > > Key: JDKIM-19 > URL: https://issues.apache.org/jira/browse/JDKIM-19 > Project: JAMES jDKIM > Issue Type: Improvement > Components: mailet >Affects Versions: 0.2 > Environment: software, mailet >Reporter: Jerry Malcolm >Assignee: Stefano Bagnara > Fix For: 0.2 > > > I need to have separate private keys for DKIM for different domains that I > host on my server. I plan to create a database table that looks up the > private key based on the domain. I figured I could subclass your DKIMSign > mailet, override the service method, set the privateKey and > signatureTemplate variables and then call the parent service method. But it > turns out that the privateKey and signatureTemplate variables are scoped to > 'private'. I know I can just clone the entire method or even the entire > java class file. But I'd much prefer to inherit everything other than that > one little change I need. But I can't do it with private scope on the key > and template. > Request to change scope on pfivateKey and signatureTemplate variables from > private to protected to support subclassing of this mailet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Updated: (JDKIM-18) jdkim verify(InputStream) doesn't clean up temp files until shutdown
[ https://issues.apache.org/jira/browse/JDKIM-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara updated JDKIM-18: - Fix Version/s: 0.2 > jdkim verify(InputStream) doesn't clean up temp files until shutdown > > > Key: JDKIM-18 > URL: https://issues.apache.org/jira/browse/JDKIM-18 > Project: JAMES jDKIM > Issue Type: Bug > Components: library >Affects Versions: 0.2 > Environment: Verified this in solaris 10 and ubuntu 10.04 > java 1.6.0_13 >Reporter: Ben Aldrich >Assignee: Stefano Bagnara >Priority: Critical > Fix For: 0.2 > > > When you pass jdkim an input stream like so : > new DKIMVerifier().verify(new ByteArrayInputStream(sb.toString().getBytes())); > the jkdim impl/Message.java creates a mime4j temp file that doesn't get > deleted until the application exits. This causes any system that runs as a > daemon to eventually run out of disk space. > I did a quick test and replaced Message.java with my own implementation using > the regular javax MimeMessage to pull out the headers and the app no longer > creates the temp files. This isn't really a good solution though because now > I can't pass simple canonicalization. I don't know mime4j very well but > digging through the source it only sets the deleteOnExit flag by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Updated: (JDKIM-19) Change scope on 2 variables in DKIMSign to support subclassing
[ https://issues.apache.org/jira/browse/JDKIM-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara updated JDKIM-19: - Fix Version/s: 0.2 Affects Version/s: 0.2 > Change scope on 2 variables in DKIMSign to support subclassing > -- > > Key: JDKIM-19 > URL: https://issues.apache.org/jira/browse/JDKIM-19 > Project: JAMES jDKIM > Issue Type: Improvement > Components: mailet >Affects Versions: 0.2 > Environment: software, mailet >Reporter: Jerry Malcolm >Assignee: Stefano Bagnara > Fix For: 0.2 > > > I need to have separate private keys for DKIM for different domains that I > host on my server. I plan to create a database table that looks up the > private key based on the domain. I figured I could subclass your DKIMSign > mailet, override the service method, set the privateKey and > signatureTemplate variables and then call the parent service method. But it > turns out that the privateKey and signatureTemplate variables are scoped to > 'private'. I know I can just clone the entire method or even the entire > java class file. But I'd much prefer to inherit everything other than that > one little change I need. But I can't do it with private scope on the key > and template. > Request to change scope on pfivateKey and signatureTemplate variables from > private to protected to support subclassing of this mailet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Assigned: (JDKIM-19) Change scope on 2 variables in DKIMSign to support subclassing
[ https://issues.apache.org/jira/browse/JDKIM-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara reassigned JDKIM-19: Assignee: Stefano Bagnara > Change scope on 2 variables in DKIMSign to support subclassing > -- > > Key: JDKIM-19 > URL: https://issues.apache.org/jira/browse/JDKIM-19 > Project: JAMES jDKIM > Issue Type: Improvement > Components: mailet >Affects Versions: 0.2 > Environment: software, mailet >Reporter: Jerry Malcolm >Assignee: Stefano Bagnara > Fix For: 0.2 > > > I need to have separate private keys for DKIM for different domains that I > host on my server. I plan to create a database table that looks up the > private key based on the domain. I figured I could subclass your DKIMSign > mailet, override the service method, set the privateKey and > signatureTemplate variables and then call the parent service method. But it > turns out that the privateKey and signatureTemplate variables are scoped to > 'private'. I know I can just clone the entire method or even the entire > java class file. But I'd much prefer to inherit everything other than that > one little change I need. But I can't do it with private scope on the key > and template. > Request to change scope on pfivateKey and signatureTemplate variables from > private to protected to support subclassing of this mailet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JDKIM-18) jdkim verify(InputStream) doesn't clean up temp files until shutdown
[ https://issues.apache.org/jira/browse/JDKIM-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898743#action_12898743 ] Stefano Bagnara commented on JDKIM-18: -- Thank you! I'm on vacation... but I'll take care of this in a couple of weeks. > jdkim verify(InputStream) doesn't clean up temp files until shutdown > > > Key: JDKIM-18 > URL: https://issues.apache.org/jira/browse/JDKIM-18 > Project: JAMES jDKIM > Issue Type: Bug > Components: library >Affects Versions: 0.2 > Environment: Verified this in solaris 10 and ubuntu 10.04 > java 1.6.0_13 >Reporter: Ben Aldrich >Assignee: Stefano Bagnara >Priority: Critical > > When you pass jdkim an input stream like so : > new DKIMVerifier().verify(new ByteArrayInputStream(sb.toString().getBytes())); > the jkdim impl/Message.java creates a mime4j temp file that doesn't get > deleted until the application exits. This causes any system that runs as a > daemon to eventually run out of disk space. > I did a quick test and replaced Message.java with my own implementation using > the regular javax MimeMessage to pull out the headers and the app no longer > creates the temp files. This isn't really a good solution though because now > I can't pass simple canonicalization. I don't know mime4j very well but > digging through the source it only sets the deleteOnExit flag by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Assigned: (JDKIM-18) jdkim verify(InputStream) doesn't clean up temp files until shutdown
[ https://issues.apache.org/jira/browse/JDKIM-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara reassigned JDKIM-18: Assignee: Stefano Bagnara > jdkim verify(InputStream) doesn't clean up temp files until shutdown > > > Key: JDKIM-18 > URL: https://issues.apache.org/jira/browse/JDKIM-18 > Project: JAMES jDKIM > Issue Type: Bug > Components: library >Affects Versions: 0.2 > Environment: Verified this in solaris 10 and ubuntu 10.04 > java 1.6.0_13 >Reporter: Ben Aldrich >Assignee: Stefano Bagnara >Priority: Critical > > When you pass jdkim an input stream like so : > new DKIMVerifier().verify(new ByteArrayInputStream(sb.toString().getBytes())); > the jkdim impl/Message.java creates a mime4j temp file that doesn't get > deleted until the application exits. This causes any system that runs as a > daemon to eventually run out of disk space. > I did a quick test and replaced Message.java with my own implementation using > the regular javax MimeMessage to pull out the headers and the app no longer > creates the temp files. This isn't really a good solution though because now > I can't pass simple canonicalization. I don't know mime4j very well but > digging through the source it only sets the deleteOnExit flag by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-745) XMLVirtualUserTable and JDBCVirtualUserTable not work symetric
[ https://issues.apache.org/jira/browse/JAMES-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898616#action_12898616 ] Stefano Bagnara commented on JAMES-745: --- I'm with Eric. Swithing to "*" and making all of the implementations to work the same way, documenting the backward incompatibility. When we break compatibility it's better to break a lot instead of introduce small and unexpected changes in behaviours (so I prefer to change the wildcard while we change the wildcard behaviour). > XMLVirtualUserTable and JDBCVirtualUserTable not work symetric > -- > > Key: JAMES-745 > URL: https://issues.apache.org/jira/browse/JAMES-745 > Project: JAMES Server > Issue Type: Bug >Affects Versions: 2.2.0, 2.3.0 >Reporter: Norman Maurer >Assignee: Eric Charles > Fix For: 3.0-M1 > > > from ml: > Looking at the virtualusertable query I see that if I only add the rule > user=bago > domain=% > target=b...@catchalldomain.com > It will never alias any recipient: neither b...@someremotedomain nor > b...@somelocaldomain. > If I instead add another generic mapping referring to the domain like: > user=nonexistinguser > domain=somedomain > target=nonexistingu...@somedomain > (yes, this does not change anything, but I need to add it to make the > previous work) > Then a message to b...@somedomain will be rewritten to b...@catchalldomain.com > This is the query: > -- > SELECT VirtualUserTable.target_address > FROM VirtualUserTable, VirtualUserTable as VUTDomains > WHERE > (VirtualUserTable.user like ? OR VirtualUserTable.user like '\%') > AND > (VirtualUserTable.domain like ? OR >(VirtualUserTable.domain like '\%' AND VUTDomains.domain like ?)) > ORDER BY > concat(VirtualUserTable.user,'@',VirtualUserTable.domain) desc > LIMIT 1 > --- > And the key/guilty part is the self-join and the "AND VUTDomains.domain like > ?" > This mean that domain=% will match any domain already used in another rule. > This is not documented anywhere and I also think this is not an intended > behaviour. > Was this hack used to try to alias only local domains? > Should we change it to consider % valid for any local domain (specified in > servernames) even if not used in other mapping rules and document it this way? > Do we need to introduce a new wildcard to specify ANY domain (even the non > local)? > On the other side the XMLVirtualUserTable seems to have not such behaviour > and to always rewrite any domain, even remote one or domains not used in > other mapping rules. > So what is the intended behaviour? I think that is really bad that XML and > JDBC behave differently wrt this issue. > My preference is: > 1) use the XML behaviour by default when using % > 2) optionally introduce later a new wildcart to match only local domains > (this can be already achieved by using HostIsLocal matcher for the virtual > users table. > This means: remove the self join and the where condition on VUTDomains from > JDBCVirtualUserTable. > WDYT? > Stefano -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Commented: (JAMES-1035) XML/JDBCVirtualUserTable should not implement DomainList
[ https://issues.apache.org/jira/browse/JAMES-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898614#action_12898614 ] Stefano Bagnara commented on JAMES-1035: IIRC implementing DomainList was a need in order to configure James with JDBCVirtualUserTable and still use the same bean also for the server domain list. This way you have a single db table for users and domains are "computed" from enlisted rules. I'm not suggesting we should revert this commit, just explaining how it worked! I'm not up to date with the current trunk, so maybe now we have a smarter way to manage multi domain virtual user tables and domains without the need to reconfigure/restart james: in this case maybe we should add at least a comment here on how to do that now. > XML/JDBCVirtualUserTable should not implement DomainList > > > Key: JAMES-1035 > URL: https://issues.apache.org/jira/browse/JAMES-1035 > Project: JAMES Server > Issue Type: Bug > Components: James Core >Affects Versions: Trunk >Reporter: Eric Charles >Assignee: Eric Charles > Fix For: 3.0-M1 > > > VirtualUserTable (AbstractVirtualUserTable and its implementations) > implements DomainList but should not be related to the domain management. > We should remove "implements DomainList" and its implementation methods. > We should also remove the mentions in spring-beans.xml as possible > "domainlist" bean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (JDKIM-16) Upgrade to mime4j 0.7 because with 0.5/0.6 there are signing issues.
[ https://issues.apache.org/jira/browse/JDKIM-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara resolved JDKIM-16. -- Resolution: Fixed > Upgrade to mime4j 0.7 because with 0.5/0.6 there are signing issues. > > > Key: JDKIM-16 > URL: https://issues.apache.org/jira/browse/JDKIM-16 > Project: JAMES jDKIM > Issue Type: Task >Affects Versions: 0.2 >Reporter: Stefano Bagnara >Assignee: Stefano Bagnara > Fix For: 0.2 > > > mime4j is only used as an optional dependency for mime parsing. Unfortunately > mime4j 0.5 requires jdkim to extend basic objects to do the header parsing. > mime4j 0.7 would be slightly better for this, but it is not released yet. > Update: due to a bug in mime4j 0.5/0.6 we cannot succesfully sign/verify some > message using that libraries. So we have to move to 0.7-SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Resolved: (JDKIM-17) Upgrade to java5 & mime4j 0.6 (and generics)
[ https://issues.apache.org/jira/browse/JDKIM-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara resolved JDKIM-17. -- Resolution: Fixed > Upgrade to java5 & mime4j 0.6 (and generics) > > > Key: JDKIM-17 > URL: https://issues.apache.org/jira/browse/JDKIM-17 > Project: JAMES jDKIM > Issue Type: Task > Components: library >Affects Versions: 0.2 >Reporter: Stefano Bagnara >Assignee: Stefano Bagnara > Fix For: 0.2 > > > Let's upgrade to java5 so we can use mime4j 0.6 & later and have better code > using generics. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Updated: (JDKIM-16) Upgrade to mime4j 0.7 because with 0.5/0.6 there are signing issues.
[ https://issues.apache.org/jira/browse/JDKIM-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Bagnara updated JDKIM-16: - Summary: Upgrade to mime4j 0.7 because with 0.5/0.6 there are signing issues. (was: Define whether to release against mime4j 0.5 or to wait for 0.7 and upgrade.) Description: mime4j is only used as an optional dependency for mime parsing. Unfortunately mime4j 0.5 requires jdkim to extend basic objects to do the header parsing. mime4j 0.7 would be slightly better for this, but it is not released yet. Update: due to a bug in mime4j 0.5/0.6 we cannot succesfully sign/verify some message using that libraries. So we have to move to 0.7-SNAPSHOT. was:mime4j is only used as an optional dependency for mime parsing. Unfortunately mime4j 0.5 requires jdkim to extend basic objects to do the header parsing. mime4j 0.7 would be slightly better for this, but it is not released yet. > Upgrade to mime4j 0.7 because with 0.5/0.6 there are signing issues. > > > Key: JDKIM-16 > URL: https://issues.apache.org/jira/browse/JDKIM-16 > Project: JAMES jDKIM > Issue Type: Task >Affects Versions: 0.2 >Reporter: Stefano Bagnara >Assignee: Stefano Bagnara > Fix For: 0.2 > > > mime4j is only used as an optional dependency for mime parsing. Unfortunately > mime4j 0.5 requires jdkim to extend basic objects to do the header parsing. > mime4j 0.7 would be slightly better for this, but it is not released yet. > Update: due to a bug in mime4j 0.5/0.6 we cannot succesfully sign/verify some > message using that libraries. So we have to move to 0.7-SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Created: (JDKIM-17) Upgrade to java5 & mime4j 0.6 (and generics)
Upgrade to java5 & mime4j 0.6 (and generics) Key: JDKIM-17 URL: https://issues.apache.org/jira/browse/JDKIM-17 Project: JAMES jDKIM Issue Type: Task Components: library Affects Versions: 0.2 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Fix For: 0.2 Let's upgrade to java5 so we can use mime4j 0.6 & later and have better code using generics. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] Created: (JDKIM-16) Define whether to release against mime4j 0.5 or to wait for 0.7 and upgrade.
Define whether to release against mime4j 0.5 or to wait for 0.7 and upgrade. Key: JDKIM-16 URL: https://issues.apache.org/jira/browse/JDKIM-16 Project: JAMES jDKIM Issue Type: Task Affects Versions: 0.2 Reporter: Stefano Bagnara Assignee: Stefano Bagnara Fix For: 0.2 mime4j is only used as an optional dependency for mime parsing. Unfortunately mime4j 0.5 requires jdkim to extend basic objects to do the header parsing. mime4j 0.7 would be slightly better for this, but it is not released yet. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
