I'm trying to upgrade my Clojure web app to the latest version of lib-noir and it's failing to compile because middleware/war-handler no longer exists. If I remove "(def war-handler (middleware/war-handler app))" from my app will it still work correctly?
war-handler was removed in this commit because it was deemed no longer necessary. From the cahnge it looks like you can now use wrap-base-url or app-handler to get the same effect.
Related
We have a quite big application built on the version 1.8.1. We would like to migrate to version 2.0 or higher. We have a few guestions:
Does exist some step-by-step manual how to do it?
Can we use 2 different versions of ember in the same time? Because of continuous migration...
We would like to avoid overwriting of the whole application...
I would suggest you to update the ember. and keep deprecation warnings open. Then you can try investigating each warning one by one and update the code with the new syntax.
This guide can be very useful : Upgrade to ember 2.x step-by step
Since Ember uses global window scope, it will result in conflicts and its not advisable to use two versions of ember.
It's possible to load different Ember versions based on which route you are on, but I really don't recommend doing that, as you lose all the benefits of having a Single Page App (apps will load again when you transition between them), and you end up doing significantly more work for yourself, with more opportunities to screw up. I'd follow locks' advice and upgrade the app step by step, testing as you go.
Since some upgrades, the ember-data-latest no longer works with my code. For now, I would still like to finish my project on the outdated version before upgrading. Specifically, I would like to know where I can find versions of these online:
Ember-data: v0.13-54-g105cfc1
Ember: Version: v1.0.0-rc.6.1
Ember: Version: v1.0.0-rc.6-62-g213039a
I think beside from forking the repo and checking out the tags you need and build it yourself, a place to go is: http://builds.emberjs.com/
But hurry, I'm not sure how long it will stay there.
IMHO you should make the effort an port everything ember to the new releases.
Hope it helps anyway.
I am developing an Django application using the Django 1.3.1 release :
https://code.djangoproject.com/browser/django/tags/releases/1.3.1
I encountered a bug, which has been identified and fixed by the Django team :
https://code.djangoproject.com/ticket/16128
The changeset associated to the bug resolution is located in Django trunk
https://code.djangoproject.com/changeset/17755
My question is : how can I take advantage of the bug resolution, without upgrading to the Django trunk version ?
There a bunch of files attached to the ticket, the latest is :
https://code.djangoproject.com/attachment/ticket/16128/16128.diff
I can see that this file is a standard 'diff' file, which can be processed by the 'patch' utility. I tried to apply it on my django 1.3.1 installation (on a dev machine), but it does not work...The source lines (to be replaced) are not exactly the one expected by the diff file.
To which 'start state' does refer this diff file ? In other words, to which django version can it be applied ?
Is there another way than applying it 'manually' ? Even if I apply it manually, I can see that the patched code call new versions of methods not included in the patch...which means that I have to find out, by reading the code, which other files have to be patched, and patch them...
At this point, I think something like : "waow, it's to complicated, let's wait the next release of Django - 1.5, for this ticket - and find a workaround !". But, in other hand, if the patch system exists, it must be possible to apply this patch to my Django 1.3.1 installation...
Did anyone encountered the same kind of problem ? If so, how did you manage it ?
Thanks in advance for your help
Did you actually try with the Django 1.4 release, which has been issued a few days ago? I am quite sure it is part of it.
Anyways...you can get the official diff at the changeset page that you referenced - at the bottom there is a link to an unified diff. You can download the patch from there and use it to patch(1) your release (beware that should the Django team release a new security release of Django 1.3, you may have to apply it again). However, those diffs are always against the most recent codebase at the time the patch has been committed. For that reason, sometimes you might have a bad luck (like in the case you have described above) and it may not apply cleanly to the previous release. In such case you would have to track down all the changes required to make it work, which may be pretty much work and might be unacceptable. So there are only three options: find your own way to work the bug around, track all the changes required to apply the patch cleanly, or upgrade to the given revision.
With the move from SproutCore 2.0 to EmberJS there was the namespace and Github repo migration. Core things seem to have moved to the http://github.com/emberjs organization Github account while there are some others that seem to have been moved to the "addons" account http://github.com/emberjs-addons.
I am currently investigating EmberJS for use with a RESTful server, serving up JSON.
My question is: Do I use the new http://github.com/emberjs/data code or the older http://github.com/emberjs-addons/sproutcore-datastore code? I would assume the former but I would just like to be sure as well as get some clarification on what is going on with the old SproutCore "addons".
The emberjs-addons are ports from the old sproutcore ecosystem. They are not modified and it looks like they are not receiving much attention from the emberjs core-team. They are concentrating on the new "emberjs-data". However, the old datastore is production proven and the modified version does work fine with the current emberjs relase (0.9.3).
In contrast, while the rewritten version looks really nice, it is explicitly stated in the projects readme that it is not considered "production ready", yet.
Which one should you choose? In my opinion that depends on your project. If you are looking for something stable or you want to put your app in production any time soon, I would give the "old" sproutcore datastore a go. On the other hand, if you are just starting with your project use the new and shiny "emberjs-data" but be warned that you might have to fight around some edges.
I have been using ember-models with my own REST adapter while I am waiting for the ember-models one to be completed. git://github.com/ebryn/ember-model.git
I'm working on upgrading an app from MX7 to 9 and testing it on my Mac's Dev server. I have a page with a large cfswitch--20 or so different cases, but none more than about 10-12 lines long. In CF9 only, whenever one of these cases does a cfinclude (which is almost all of them), I get an error along the lines of:
org.apache.bcel.generic.ClassGenException: Invalid branch target position offset for jsr[168](3):-1: -1: astore[58](2) 27 at
cfindex2ecfm581352809._factor4(/Users/dlaughland/Workspace/abcapp/surveymanager /surveys/survey/index.cfm:34) at
cfindex2ecfm581352809._factor28(/Users/dlaughland/Workspace/abcapp/surveymanager/surveys/survey/index.cfm:33) at
cfindex2ecfm581352809.runPage(/Users/dlaughland/Workspace/abcapp/surveymanager/surveys/survey/index.cfm:1) at
cfApplication2ecfc1705547767$funcONREQUEST.runFunction(/Users/dlaughland/Worksp ace/abcapp/Application.cfc:215)
I have googled extensively, and the best explanation I can find is a JDK error that was supposedly fixed in MX7! What is causing this? How do I fix it? This isn't the only page with a large cfswitch so I really don't want to re-write everything into cfif structures.
You can file a bug, but here are some steps that might help you work around the issue.
Try updating your JRE version, you can get the latest and greatest here. You can then ask CF to use that JRE via your CF Admin > Server Settings > Java and JVM. Further instructions here.
Try using a servlet container, for example use Tomcat instead of the bundled JRun. Here are some instructions.
Can I ask if you are going to use this in production on a Mac? If not, try running your code on a OS that will mirror your live site. The bug (if it is a bug) may not be in that version of CF.
Hope something there helps.
If you upgraded from CF7 to CF9 with the code already on the server, try deleting all of the classes from WEB-INF/cfclasses and restarting CF.