41 views
Skip to first unread message

Graeme Defty

unread,
Jul 1, 2014, 10:28:49 AM7/1/14
to chica...@googlegroups.com
Well maybe just 1 more error . . .

previously my links such as "/static/blah/blah" would access static files <<app>>/prov/static/blah/blah"

Now I get errors accessing file <<app>/priv//static/blah/blah"  (note the double "/")

However, if I take off the leading "/" from the link, I get reports of "unknown action 'static'" on whatever controller I happen to be on.

Any suggestions?

g


Graeme Defty

unread,
Jul 3, 2014, 1:33:19 AM7/3/14
to chica...@googlegroups.com
OK - so you live and learn . . . multiple '/' characters in a path are fine - the extra ones are just ignored, so I have replaced all my leading slashes.

But why then are my files not found?

It appears to be the '../priv/' at the front of the path is taking me one level too high. It is the priv directory which is not being found.

I created a link in the directory ABOVE my application directory, called it priv and pointed it to the priv directory within the application and all was well.

SOOOooooo - looks like the '../priv/' added to the beginning of the path should have been './priv/'.

BUT - why am I the only one having this issue? It seems pretty fundamental. Clearly I have something else set up incorrectly.

Any ideas, anyone?

g



--
You received this message because you are subscribed to the Google Groups "ChicagoBoss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chicagoboss...@googlegroups.com.
Visit this group at http://groups.google.com/group/chicagoboss.
To view this discussion on the web visit https://groups.google.com/d/msgid/chicagoboss/CAKF5fiB0086_jmnCj3bz4wqs7mWJmWj4dROHUjAgT%2B9OFUopdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Graeme Defty

unread,
Jul 3, 2014, 6:30:16 AM7/3/14
to chica...@googlegroups.com
Got it! Well . . . at least I have found the offending (to me) code and found a (partial) fix.

In boss_web_controller_handle_request:build_static_response/4 there is a call to make_etag/3. This function looks like this:

make_etag(App, StaticPrefix, File) ->
    Priv = case code:priv_dir(App) of
        {error, bad_name} ->
            %% enuit isn't loading the application, so this will default for us
            "../priv";
        P ->
            P
    end,
   --- etc ---

That double '.' on the 5th line is what is causing my problems. If I delete on of those '.'s everything works fine.

So why did nobody else suffer from this problem?

The code at that point seems to be handling cases where the application's priv_dir is not being found. I am guessing I am the only one in this situation whereas nobody else is.

And why is that? I think it comes back to the issue of the application and the directory not being named the same. If I go to the command line and type

code:priv_dir(app_name).

I do indeed get the response {error, bad_name}.

However if I type:

code:priv_dir(dir_name).

the response is the correct path to my priv dir.

SOOooooooooooo . . .

I think that the code should read:

make_etag(App, StaticPrefix, File) ->
    AppDir = boss_env:get_env(App, path, ""),
    Priv = case code:priv_dir(AppDir) of
        {error, bad_name} ->
            %% enuit isn't loading the application, so this will default for us
            "./priv";
        P ->
            P
    end,


HOWEVER, this does not work because boss_env:get_env does not return the correct value for path. It returns 'undefined'.

I have checked my boss.config and it looks fine.

Is there a problem with boss setting up the attributes in the boss.config file as attributes of my application?

Thanks  (and sorry for rambling on a bit)

g






Jesse Gumm

unread,
Jul 3, 2014, 7:36:06 PM7/3/14
to chica...@googlegroups.com
Hi Graeme,

As you've noted, you're definitely getting burned by the fact that
your app and its containing directory aren't the same.

Give this a shot:

./rebar boss c=compile

Then run init and see if your change works.

What is your current path set to in boss.config (for your app, not for 'boss')?
> https://groups.google.com/d/msgid/chicagoboss/CAKF5fiBdAJojy9%2B%3D980Hj%3DnEzyc0s2D7z8YAVgZ-V%2BVcfRp3ew%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



--
Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm

Graeme Defty

unread,
Jul 3, 2014, 9:05:07 PM7/3/14
to chica...@googlegroups.com
Hi Jesse,

In the past I have never been able to compile the app in dev, though on the production server it was fine. Now I realise this was almost certainly tied up with the naming conventions. I run 4 instances on the production server, but in each case the app name is reflected in the name of the directory.

Previously trying to compile in dev gave an error in init. This time we seem to have moved a little further through the process because it took a little longer and gave the following:

graeme@graeme-IdeaPad-S410p:~/projects/egolf/dev/prodfix$  ./rebar boss c=compile==> prodfix (boss)
07:52:03.419 [info] Application lager started on node nonode@nohost
ERROR: boss failed while processing /home/graeme/projects/egolf/dev/prodfix: {'EXIT',
    {undef,
        [{rebar_config,get_global,
             [{config,"/home/graeme/projects/egolf/dev/prodfix",
                  [{plugin_dir,["priv/rebar"]},
                   {plugins,[boss_plugin]},
                   {eunit_compile_opts,[{src_dirs,["src/test"]}]},
                   {edoc_opts,[no_packages,private]},
                   local]},
              verbose,0],
             []},
         {boss_rebar,compile,4,
             [{file,"../ChicagoBoss-0.8.12/priv/rebar/boss_rebar.erl"},
              {line,100}]},
         {boss_plugin,boss,2,[{file,"priv/rebar/boss_plugin.erl"},{line,33}]},
         {rebar_core,run_modules,4,[]},
         {rebar_core,execute,4,[]},
         {rebar_core,process_dir0,6,[]},
         {rebar_core,process_commands,2,[]},
         {rebar,main,1,[]}]}}
graeme@graeme-IdeaPad-S410p:~/projects/egolf/dev/prodfix$


The application section of my boss.config file looks ike this:

{egolf, [
    {path,"../prodfix"},
    {base_url, "/"}
]}

so I should be able to pick up my path through

AppDir = boss_env:get_env(App, path, ""),

as in the change i suggested, yes?


Thanks for your help,

g



Jesse Gumm

unread,
Jul 5, 2014, 12:07:45 PM7/5/14
to chica...@googlegroups.com
Hey Graeme,

From what I see, it would look like that *should* work, but the whole
app/priv dir stuff is always finicky.

That said, the undef with the rebar_config:get_global is rather
puzzling. It hints that perhaps the version of rebar you're running is
out of date. What do you get from:

rebar --version
> https://groups.google.com/d/msgid/chicagoboss/CAKF5fiB10rEiBGxwVC13_cKumn7PRkbKGVknTODGEiz3hDWhQg%40mail.gmail.com.

Graeme Defty

unread,
Jul 6, 2014, 6:08:57 AM7/6/14
to chica...@googlegroups.com
Jesse,

I THINK it is OK because I recently g​enerated a new project to check my structure was not missing anything and I am fairly sure I copied rebar across.

Anyway, I get the following:

$ ./rebar --version
rebar version: 2 date: 20120209_044624 vcs: git 1c1a32b

Not sure if this is good or bad.

g


 





Jesse Gumm

unread,
Jul 9, 2014, 3:52:48 PM7/9/14
to chica...@googlegroups.com
Whoa, sorry, I forgot I didn't respond to this - this was a hell of a weekend.

That version is definitely out of date.

From the latest version of CB:
$ ./rebar --version
rebar 2.2.0 R16B02 20140228_085107 git 2.2.0-20-g6e24cd6-dirty

Try cloning the latest HEAD and copy that rebar into your app, or just
download from https://github.com/ChicagoBoss/ChicagoBoss/raw/master/skel/rebar

But you'll probably have to `chmod a+x rebar` if you do the latter.
> --
> You received this message because you are subscribed to the Google Groups
> "ChicagoBoss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chicagoboss...@googlegroups.com.
> Visit this group at http://groups.google.com/group/chicagoboss.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/chicagoboss/CAKF5fiA6inb5RGrnn9m0%2BuDsWchEmPT_e4cXbLB%2B%3DhmNhzncnQ%40mail.gmail.com.

Graeme Defty

unread,
Jul 10, 2014, 12:10:50 AM7/10/14
to chica...@googlegroups.com
Hi Jesse,

No problem on the timing, but the new rebar gave me exactly the same result.  :-(

I have not looked into the rebar source, but if I had to guess I would put money on the fact that rebar_config:get_global uses the same mechanism as boss_env:get_env, i.e. a call to application:get_env/2

I traced my original problem back to the fact that my call boss_env:get_env(App, path, "") was returning 'undefined', and I would lay a pound to a penny that this issue in compiling boils down to the same problem.

I even get 'undefined' when I run boss_env:get_env(App, path, "") from the command line.

g




Reply all
Reply to author
Forward
0 new messages