wrap-multipart-params

86 views
Skip to first unread message

abel...@yahoo-inc.com

unread,
Jun 18, 2016, 4:05:46 PM6/18/16
to Ring
Hello

When I upgraded wrap-multipart-params to version 1.3 (from 1.1), I had to add a new use directive to my namespace for:  ring.middleware.multipart-params.temp-file, otherwise the multipart middleware causes an exception that it cannot find that namespace at runtime.

So the use block (in my namespace) for the multipart-params went from: 
(:use  ring.middleware.multipart-params)

to

(:use  ring.middleware.multipart-params
          ring.middleware.multipart-params.temp-file)

Not a huge deal, other than I have to know about this implementation detail from my namespace. I am wondering though why (from clojure's perspective) I now have to specify this. From this change alone, I don't see why this is the case:


Thanks,

Alessandro

James Reeves

unread,
Jun 18, 2016, 4:08:42 PM6/18/16
to Ring
Were you using temp-file-store implicitly via the default value, or as an explicit option?

- James

--
You received this message because you are subscribed to the Google Groups "Ring" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ring-clojure...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

abel...@yahoo-inc.com

unread,
Jun 18, 2016, 4:36:09 PM6/18/16
to Ring, ja...@booleanknot.com
Hi James

Implicitly, so my method of calling it hasn't changed.

Update: I did make another change which was that compojure was apparently bringing some of ring-core into my classpath, so I've told maven to exclude that using dependency exclusions. I am not sure this is required, and it seems to be causing issues (I am not sure why exactly). The main thing I see that could be an issue is that compojure wants ring 1.3.1, and my project has 1.3.0 specified... What is the difference between these two?

Here's the pertinent section in the pom:

          <dependency>
              <groupId>compojure</groupId>
              <artifactId>compojure</artifactId>
              <exclusions>
                  <exclusion>
                      <groupId>ring</groupId>
                      <artifactId>ring-core</artifactId>
                  </exclusion>
              </exclusions>
          </dependency>
....
          <dependency>
              <groupId>ring</groupId>
              <artifactId>ring-core</artifactId>
          </dependency>

If I remove the exclusion, temp_file is found without the added use clause and things appear to work after that. But I don't understand why I need the extra use with the exclusion, doesn't seem like that should be the case. I have limited knowledge of how dependencies get resolved, so that is adding to my confusion.

Thanks,

Alessandro

James Reeves

unread,
Jun 18, 2016, 4:47:59 PM6/18/16
to Ring
On 18 June 2016 at 21:36, abellina via Ring <ring-c...@googlegroups.com> wrote:
Implicitly, so my method of calling it hasn't changed.

You shouldn't need to use ring.middleware.multipart-params.tempfile explicitly. It's loaded when you start the middleware.

I'd be interested in seeing the stacktrace you're getting. Also, are you using :aot :all or AOT in any capacity?
 
Update: I did make another change which was that compojure was apparently bringing some of ring-core into my classpath, so I've told maven to exclude that using dependency exclusions. I am not sure this is required, and it seems to be causing issues (I am not sure why exactly). The main thing I see that could be an issue is that compojure wants ring 1.3.1, and my project has 1.3.0 specified... What is the difference between these two?

Ring 1.3.1 has some additional bug fixes. Check the HISTORY.md file in the repository for a more detailed breakdown.

I'm also curious why you're upgrading from a four-year-old version or Ring, to a two-year-old version of Ring. Why not upgrade directly to the latest version? Is it because you require Clojure 1.3.0 compatibility?

- James

abel...@yahoo-inc.com

unread,
Jun 18, 2016, 4:59:41 PM6/18/16
to Ring, ja...@booleanknot.com


On Saturday, June 18, 2016 at 3:47:59 PM UTC-5, James Reeves wrote:
On 18 June 2016 at 21:36, abellina via Ring <ring-c...@googlegroups.com> wrote:
Implicitly, so my method of calling it hasn't changed.

You shouldn't need to use ring.middleware.multipart-params.tempfile explicitly. It's loaded when you start the middleware.

If I match the compojure ring-core version, the issue I reported goes away. I don't know why this is..
 

I'd be interested in seeing the stacktrace you're getting. Also, are you using :aot :all or AOT in any capacity?

We use gen-class. This is for apache storm.
 
 
Update: I did make another change which was that compojure was apparently bringing some of ring-core into my classpath, so I've told maven to exclude that using dependency exclusions. I am not sure this is required, and it seems to be causing issues (I am not sure why exactly). The main thing I see that could be an issue is that compojure wants ring 1.3.1, and my project has 1.3.0 specified... What is the difference between these two?

Ring 1.3.1 has some additional bug fixes. Check the HISTORY.md file in the repository for a more detailed breakdown.

The diff between 1.3.0 and 1.3.1 doesn't seem show anything weird (https://github.com/ring-clojure/ring/compare/1.3.0...1.3.1)
 

I'm also curious why you're upgrading from a four-year-old version or Ring, to a two-year-old version of Ring. Why not upgrade directly to the latest version? Is it because you require Clojure 1.3.0 compatibility?

I am making a change s.t. the caching behavior improves in the storm ui, but I didn't want to introduce a bunch of new versions if I didn't need to (e.g. we are also on Jetty 7), that's why I am staying near the version they were at. I'll investigate moving to 1.5, but that's probably a different task.
 

- James

James Reeves

unread,
Jun 18, 2016, 5:23:20 PM6/18/16
to Ring
On 18 June 2016 at 21:59, abellina via Ring <ring-c...@googlegroups.com> wrote:
On Saturday, June 18, 2016 at 3:47:59 PM UTC-5, James Reeves wrote:
On 18 June 2016 at 21:36, abellina via Ring <ring-c...@googlegroups.com> wrote:
Implicitly, so my method of calling it hasn't changed.

You shouldn't need to use ring.middleware.multipart-params.tempfile explicitly. It's loaded when you start the middleware.

If I match the compojure ring-core version, the issue I reported goes away. I don't know why this is..

Have you tried cleaning your target directory? Between 1.3.0 and 1.3.1, nothing in the multipart namespace was changed, so I can't think why one would work and the other wouldn't.
 
I'm also curious why you're upgrading from a four-year-old version or Ring, to a two-year-old version of Ring. Why not upgrade directly to the latest version? Is it because you require Clojure 1.3.0 compatibility?

I am making a change s.t. the caching behavior improves in the storm ui, but I didn't want to introduce a bunch of new versions if I didn't need to (e.g. we are also on Jetty 7), that's why I am staying near the version they were at. I'll investigate moving to 1.5, but that's probably a different task.

Ring uses semantic versioning, so its versions are in major.minor.patch form. Minor version changes should be backward compatible, but add new features. Patches are purely bug fixes. If you want to be conservative, I'd suggest updating to 1.3.2, rather than 1.3.0.

- James

abel...@yahoo-inc.com

unread,
Jun 20, 2016, 9:32:52 AM6/20/16
to Ring, ja...@booleanknot.com
James

So it turns what I thought was working was due to target directory not being clean.

You wanted to see the full exception:

java.io.FileNotFoundException: Could not locate org/apache/storm/shade/ring/middleware/multipart_params/temp_file__init.class or org/apache/storm/shade/ring/middleware/multipart_params/temp_file.clj on classpath. Please check that namespaces with dashes use underscores in the Clojure file name.
at clojure.lang.RT.load(RT.java:449)
at clojure.lang.RT.load(RT.java:412)
at clojure.core$load$fn__5448.invoke(core.clj:5866)
at clojure.core$load.doInvoke(core.clj:5865)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core$load_one.invoke(core.clj:5671)
at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
at clojure.core$load_lib.doInvoke(core.clj:5710)
at clojure.lang.RestFn.applyTo(RestFn.java:142)
at clojure.core$apply.invoke(core.clj:632)
at clojure.core$load_libs.doInvoke(core.clj:5749)
at clojure.lang.RestFn.applyTo(RestFn.java:137)
at clojure.core$apply.invoke(core.clj:632)
at clojure.core$require.doInvoke(core.clj:5832)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at org.apache.storm.shade.ring.middleware.multipart_params$load_var.invoke(multipart_params.clj:71)
at org.apache.storm.shade.ring.middleware.multipart_params$fn__4829.invoke(multipart_params.clj:77)
at clojure.lang.Delay.deref(Delay.java:37)
at clojure.core$deref.invoke(core.clj:2206)
at org.apache.storm.shade.ring.middleware.multipart_params$multipart_params_request.doInvoke(multipart_params.clj:86)
at clojure.lang.RestFn.invoke(RestFn.java:423)
at org.apache.storm.shade.ring.middleware.multipart_params$wrap_multipart_params$fn__4839.invoke(multipart_params.clj:118)
at org.apache.storm.shade.ring.middleware.flash$wrap_flash$fn__5054.invoke(flash.clj:35)
at org.apache.storm.shade.ring.middleware.session$wrap_session$fn__5040.invoke(session.clj:98)
at org.apache.storm.shade.ring.util.servlet$make_service_method$fn__4589.invoke(servlet.clj:127)
at org.apache.storm.shade.ring.util.servlet$servlet$fn__4593.invoke(servlet.clj:136)
at org.apache.storm.shade.ring.util.servlet.proxy$javax.servlet.http.HttpServlet$ff19274a.service(Unknown Source)
at org.apache.storm.shade.org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:654)
at org.apache.storm.shade.org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1320)
at org.apache.storm.logging.filters.AccessLoggingFilter.handle(AccessLoggingFilter.java:47)
at org.apache.storm.logging.filters.AccessLoggingFilter.doFilter(AccessLoggingFilter.java:39)
at org.apache.storm.shade.org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1291)
at org.apache.storm.shade.org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
at org.apache.storm.shade.org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
at org.apache.storm.shade.org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1291)
at org.apache.storm.shade.org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:443)
at org.apache.storm.shade.org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044)
at org.apache.storm.shade.org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372)
at org.apache.storm.shade.org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978)
at org.apache.storm.shade.org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at org.apache.storm.shade.org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.apache.storm.shade.org.eclipse.jetty.server.Server.handle(Server.java:365)
at org.apache.storm.shade.org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:486)
at org.apache.storm.shade.org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:933)
at org.apache.storm.shade.org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:995)
at org.apache.storm.shade.org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)
at org.apache.storm.shade.org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at org.apache.storm.shade.org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.apache.storm.shade.org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668)
at org.apache.storm.shade.org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at org.apache.storm.shade.org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at org.apache.storm.shade.org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)

Storm is removing clj files from its dependencies (ring included) at build time. I assume that by adding a use, I generate extra classes in my namespace that make multipart-params work. What I don't know is how 1.3.0 is different than 1.3.1+ (other than the delay wrapper around default-store). 

Thanks

Alessandro

James Reeves

unread,
Jun 20, 2016, 10:01:50 AM6/20/16
to Ring
It sounds like Storm is trying to work out the dependencies between namespaces using the ns declaration, which isn't foolproof and is failing in this instance.

This doesn't sound like a problem with Ring itself, but how Storm packages Ring. Adding an additional "use" or "require" might be the best solution.

- James

Reply all
Reply to author
Forward
0 new messages