Closed KadekM closed 6 years ago
play-easymail
0.9.3
is not in sonatype, yet, will show up here: https://search.maven.org/#search%7Cga%7C1%7Cplay-easymail once published.
added a couple more needed changes
@KadekM There are a few problems with the latest version, can you have a look, please? See https://travis-ci.org/joscha/play-authenticate/jobs/252710668
Locally, you can make it work easily by cd code && sbt publish-local && cd ../samples/... && sbt run
@joscha yea I'll check as soon as I have a bit of time
we need to bump play ebean as well, so its a bit more work :|
@joscha there are some issues with code like circular deps which are now disallowed by play by default and I'm not sure if forcing it enabled onto clients is right way to go... just run example to see guice error
I can finish this sometimes in onwards from mid-august since until then I'm on vacation. We can start with non optimal solution of just enabling circular references (as it's now).
@KadekM any chance to wrap the work here up?
@joscha I'll look on it during weekend
Thank you!
On 21 Aug. 2017 23:57, "Marek Kadek" notifications@github.com wrote:
@joscha https://github.com/joscha I'll look on it during weekend
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/joscha/play-authenticate/pull/345#issuecomment-323749864, or mute the thread https://github.com/notifications/unsubscribe-auth/AALehvGIXEeiwAtqjq4hQT03ScISr6pCks5saYyvgaJpZM4OR_lN .
I gave it a shot, but there's no easy way to fix the cyclical dependencies... if anyone wants to continue in this PR feel free to pick it up, afaik most of the stuff is done except the cyclical dependencies in code which guice and new play dont like.
@KadekM are you able to understand which dependency is causing the problem and where? Looking at the stacktrace, I'm having some trouble understanding event where the problem is...
@gmsa sorry I don't, I haven't taken time to understand it.
Someone who knows the problem could help please?
I am waiting for 0.9 version on maven repository :(
-- edited @joscha , do you have any predictions for when you could solve this problem?
Hey Josh, Do you think you can split the code in two - one for 2.11 for 2.6 and one for 2.12 for 2.6 and then work on 2.12 first? Most people looking for upgrades are probably moving to 2.12. Plus, the other dependencies my project depends on are working with 2.6 and sbt 1.0 and 2.12 - which is kinda where I waited for 2 months to before trying to upgrade.
@backboardo2 I am not actively working on fixing this at the moment. I am happy to accept a pull request (preferably finishing up this one as a lot of time has been put into it already), but splitting the codebase into a 2.11 and 2.12 version should be the last resort.
What can we do to find a solution? Maybe you set up some sort of crowd funding to work in this issue full time until it is resolved? I think i'm not the only one who used this plugin in commercial software development and is willing to pay a reasonable amount for it. But we really need the 2.6 support now. It would be horrible to have to rewrite all my applications and look for an alternative.
I found some time today and resolved the cyclic dependency and the mailer problem. Unfortunately there are still a couple of problems:
I am unsure about how to fix the ScalaControllerSpec:
[info] Compiling 1 Scala source and 1 Java source to /Users/joscha/Development/play-authenticate/test-app/target/scala-2.12/test-classes...
[error] /Users/joscha/Development/play-authenticate/test-app/test/ScalaControllerSpec.scala:45: overloaded method value route with alternatives:
[error] [T](app: play.api.Application, req: play.api.mvc.Request[T])(implicit w: play.api.http.Writeable[T])Option[scala.concurrent.Future[play.api.mvc.Result]] <and>
[error] [T](app: play.api.Application, rh: play.api.mvc.RequestHeader, body: T)(implicit w: play.api.http.Writeable[T])Option[scala.concurrent.Future[play.api.mvc.Result]]
[error] cannot be applied to (play.api.test.FakeRequest[play.api.mvc.AnyContentAsFormUrlEncoded])
[error] val someResult = route(fakeRequestCall(
[error] ^
[error] /Users/joscha/Development/play-authenticate/test-app/test/ScalaControllerSpec.scala:55: overloaded method value route with alternatives:
[error] [T](app: play.api.Application, req: play.api.mvc.Request[T])(implicit w: play.api.http.Writeable[T])Option[scala.concurrent.Future[play.api.mvc.Result]] <and>
[error] [T](app: play.api.Application, rh: play.api.mvc.RequestHeader, body: T)(implicit w: play.api.http.Writeable[T])Option[scala.concurrent.Future[play.api.mvc.Result]]
[error] cannot be applied to (play.api.test.FakeRequest[play.api.mvc.AnyContentAsEmpty.type])
[error] val someResult = route(fakeRequestCall(
[error] ^
[error] /Users/joscha/Development/play-authenticate/test-app/test/ScalaControllerSpec.scala:67: overloaded method value route with alternatives:
[error] [T](app: play.api.Application, req: play.api.mvc.Request[T])(implicit w: play.api.http.Writeable[T])Option[scala.concurrent.Future[play.api.mvc.Result]] <and>
[error] [T](app: play.api.Application, rh: play.api.mvc.RequestHeader, body: T)(implicit w: play.api.http.Writeable[T])Option[scala.concurrent.Future[play.api.mvc.Result]]
[error] cannot be applied to (play.api.test.FakeRequest[play.api.mvc.AnyContentAsFormUrlEncoded])
[error] val someResult = route(fakeRequestCall(
[error] ^
[error] three errors found
[error] (root/test:compileIncremental) Compilation failed
[error] Total time: 3 s, completed 10/12/2017 1:02:03 PM
@tjdett @pdolega @pdolega-test are you able to help here? My Scala knowledge is not good enough I think - if it can't be fixed by one of the contributors we may just need to remove this Spec.
Deadbolt and/or user caching seem to have a problem, e.g. the UsernamePasswordAuthProvider
shows:
when using the signup page. Even though the signup page should be okay to be accessed without being auth'd. I suspect a slight change in either the cacheApi
or deadbolt2-java
(cc @schaloner) caused this. Might have something to do with https://github.com/joscha/play-authenticate/blob/0ac3c30fbb5d492614e5efaa15585d60200fbe26/samples/java/play-authenticate-usage/conf/play-authenticate/deadbolt.conf#L5-L6 as well.
Thanks to @mkurz, Deadbolt made big step forward lately and I see that a lot of things had changed (https://github.com/schaloner/deadbolt-2-java/pulls?q=is%3Apr+is%3Aclosed) so maybe he will know what is the problem with caching
@eximius313 I am not done yet with deadbolt, there a a few pull requests more coming. I hope we will release a new deadbolt version in the next weeks with a lot of enhancements.
I will take a look at this issue here as soon we released a new deadbolt version.
Hello there, I also wait for play 2.6 support! Can I help with something @mkurz?
We stopped tracking this project, will migrate to play-pac4j
@mkurz any news on deadbolt?
It's high up on my todo list, I hope I will have time to finish work on deadbolt within the next 2 to 3 weeks. Stay tuned.
I have been refreshing this page looking for updates, as I also need the updates for Play 2.6. Do you have a list of work items that need to happen in order to get this PR working? I would be willing to help, as I would rather not have to modify my app to work with another library unless there are no other options. I have been investigating Pac4J, and it will involve changing much of what I have to get that working. Thanks.
The only blocker left is deadbolt. Something seems wrong with the adapter but i am unsure what. The scala tests are nice to have but i am happy to remove them if we can't fix them. So if you are able to make deadbolt work i can create a release for 2.6
On 26/01/2018 9:00 AM, "Mule52" notifications@github.com wrote:
I have been refreshing this page looking for updates, as I also need the updates for Play 2.6. Do you have a list of work items that need to happen in order to get this PR working? I would be willing to help, as I would rather not have to modify my app to work with another library unless there are no other options. I have been investigating Pac4J, and it will involve changing much of what I have to get that working. Thanks.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/joscha/play-authenticate/pull/345#issuecomment-360614941, or mute the thread https://github.com/notifications/unsubscribe-auth/AALehpGxkgF6mDM_fYxnsHPDH57UScVlks5tOPmagaJpZM4OR_lN .
Give me 2 more weeks and I will hopefully release a new deadbolt version.
@mkurz I can wait two weeks. I appreciate your efforts. Thanks.
Hey @mkurz, just wondering how it's going? We are kinda blocked on play 2.6 and play authenticate. Ta
Hi everyone, as you can see here I did work on deadbolt the last few days. I am almost finished - there is just one fix/enhancement left I want to merge (I already know how to fix that, just takes a few hours to implement). I hope I find time the next days (maybe over the weekend? but I am not sure). I will do my best.
:tada: Breaking news: deadbolt-java
version 2.6.4
was released a couple of minutes ago.
https://github.com/schaloner/deadbolt-2-java/releases/tag/v2.6.4
🎉 Breaking news: deadbolt-java version 2.6.4 was released a couple of minutes ago.
ah, sweet, thank you @mkurz. If anyone wants to give that a try on this branch (don't forget to disable the failing scala tests, we will just remove them) that would be great. If not, I will try and squeeze in a few hours an evening this week.
seems like updating to 2.6.4
didn't do the trick alone. Still getting:
on signup, even though deadbolt should be happy - @mkurz is there an upgrade guide of some sort available? I am pretty sure I am missing some config...
Maybe the problem is not related to deadbolt?
Possibly. I can't find the reason and ran out of time for finding a fix. If someone else wants to have a stab at this, please feel free to do so, I pushed the last changes needed for the deadbolt update.
On 13 Mar. 2018 03:06, "Matthias Kurz" notifications@github.com wrote:
Maybe the problem is not related to deadbolt?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/joscha/play-authenticate/pull/345#issuecomment-372364386, or mute the thread https://github.com/notifications/unsubscribe-auth/AALehrtE-EUnppr7L2xlIKhZE6PV6Wnzks5tdpzrgaJpZM4OR_lN .
Play 2.7 M1 was just released. A 2.6 version is not available in over a year now. So we might consider this project dead, right?
@GBeushausen if @rozkerim is right, the last missing piece for 2.6 support is Ebean. I have spent quite a bit of time to try and make it work, but couldn't find the ultimate reason 2.6 doesn't work as it should. As any opensource project, it relies a bit on contributions, so if you (or anyone else) find time to make it work with 2.6 (or 2.7 even) I am more than just a little happy to release a new version.
Is Ebean the problem at this point? Ebean needs to be replaced with JPA or something in order allow upgrading to 2.6 or 2.7? Or is it something else?
no solution ? we are blocked to version 2.5 ? no one could help to make it work this great module ? the only one for playframework ?
Hi guys! I'm happy I was referred to this discussion. Please see my comments in #360 I give multiple alternatives moving forward and to get a 2.6 ready ASAP.
@bravegag Thanks for your comments. Your idea about removing Ebean in the samples was enough for me to do that locally this week in my app. I should be able to upgrade Play locally for my app. It was no easy task, but now I am free of Ebean. I am using Jooq in my app. I would think the samples could be rewritten to use any of those JPA examples you shared.
I am sharing this because I feel like rather than rewriting my app to use some other framework, I just stripped out Ebean and replaced it with Jooq, which I was using throughout my app anyway. I am using Deadbolt as well, and really the only gotcha was to make sure I have some class that implements Subject, Role, and Permission. The rest of my app can use my Jooq pojo for the user, while Deadbolt will use my "AppUser" class.
It seems like what is holding up this library from upgrading is Ebean in the samples. Thanks for your comments.
@Mule52: I don't think this is a viable solution. Many people are using ebean. I have plenty of apps written for my customers using ebean. Having to rewrite all of these with another JPA solution is plain impossible. From my experience it's much easier to migrate to pac4j which i've done for my current projects.
@GBeushausen: starting from scratch with JPA can be daunting but I thought about this long time ago when I wrote perfectjpattern. Once I manage to get the "Remember me" PR in I will re-fork and rewrite Ebean to perfectjpattern's Hibernate or OpenJPA though the former makes life a lot easier e.g. with supporting the nice DAO findByExample
. Here you don't need a DAO-per-model-type the generic DAO covers 90% of the use-cases.
I hope doing so will encourage you to switch to JPA and stay on PA.
Besides the "Remember Me" which I sponsored via Upwork, I'm thinking to also introduce Two-Factor authentication using Google's Authenticator App ... exciting stuff! and functionality that is not easy to develop from scratch for each application that builds on PA.
I feel your concerns but I still think that it is a lot easier to replace the DAO layer than coming up with a different Auth framework with all the features that PA has, also considering the user and contribution base it has.
@bravegag: That's just not how software development works. My clients have spent 30K -60K for the app i developed for them. I cannot tell them to spend another 20K just for refactoring the ORM, so that the auth framework works with the latest framework version. They get no benefits, maybe like more bugs in the first place. So they would never release the budget for such a thing.
@GBeushausen following your reasoning then why migrate to Play 2.6? they also get no extra benefits functionality-wise, an old saying in SE: don't change what works. However, moving forward you could use the new ORM tech with new clients and new project. Finally, if it bothers you so much then do something about it, pay or develop whatever it takes to fix EBean.
Again to put things into perspective, PA doesn't need EBean. EBean is just a technology choice for the samples. I have never used EBean in any project before and don't need it.
@bravegag: Migrating to Play 2.6 can have reasons customers are wiling to pay for. For example more req/s due to the new Akka HTTP server etc. There are a few things which i don't understand from your perspective. Why on earth are you planning to use such an exotic thing like "perfectjpattern"? There are only 4 questions on stack overflow about this software. Google trends doesn't even have enough data about it. This must be a joke right? I mean if you're serious about rewriting the ORM layer, why not at least use JPA / Hibernate directly? Or Spring data? But trying to get this project to use such an exotic freak that no one has ever heard of is certainly not a direction we want this project to go, do we?
@GBeushausen This is the last message I will write to you. If you are so successful, flashing and showing off earnings, and you are such a majesty in software development that you name-calling and prejudice against people and projects you don't know while the only thing I see you doing is whining and crying for features you're either unable to develop or afford. Things just don't add up.
I can sponsor or develop whatever feature I want, I really don't need you nor EBean, in my view, perfectjpattern is a good investment for my future projects but I'm also very fluent in SQL and Scala so also very happy using Slick. I will fork PA and make the samples work with perfectjpattern which is simply a thin layer on top of JPA that makes working on top of JPA and switching between JPA providers easy. Some folks will like it and use it, some folks like yourself will hate it, and that's fine.
For #343
https://github.com/joscha/play-easymail/issues/53 is required, so this builds:
"com.feth" %% "play-easymail" % "0.9.3"