Play 2.4.0-RC1 released!

[James Roper]

Hi all,

The Play team is proud to announce the release of Play 2.4.0-RC1.  This is the first release candidate for Play 2.4.0.  While it is not likely that there will be any breaking changes between now and the 2.4.0 release, it is still possible.

Major features in Play 2.4 include:

* Built in dependency injection support

* Improved testing APIs

* The ability to embed Play in other applications

* Aggregated reverse routers

* Improved support for JDK 8 APIs

* HikariCP is now the default connection pool

* Experimental akka-http backend

* Experimental reactive streams support

For a full list of major new features in Play 2.4, see the highlights:

https://www.playframework.com/documentation/2.4.0-RC1/Highlights24

To migrate from Play 2.3 to 2.4, see the migration guide:

https://www.playframework.com/documentation/2.4.0-RC1/Migration24

We encourage people to test this release out, and report any issues in the Play issue tracker.

We would like to thank the community for the many contributions made.  Many of the core features of this release have been contributed by volunteers outside of Typesafe.  In addition, according to git, a total of 163 unique committers contributed to 2.4.x, of which 116 had not contributed before, bringing the total number of unique contributors to Play to 481.

Thanks,

James

--

James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

[Yann Simon]

congrats to all!

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

[Ian Rae]

EBean 4, DI, and improved testing.  This is fantastic.  Thank you to all Play committers!

--Ian

[Viktor Klang]

Very cool, I'm looking forward to diving into the new features!

--
Cheers,
√

——————
Viktor Klang
Deputy CTO

Typesafe Inc.

--

[Markus Jura]

Great feature list! Thanks to all committers!

[Mark Moore]

Awesome news and the migration path doesn't look too difficult.  Good Work lads.

[James Ward]

Nice work!  Unfortunately I'm getting a scalaz-stream missing error again:

[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: UNRESOLVED DEPENDENCIES ::
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn] :: org.scalaz.stream#scalaz-stream_2.10;0.7a: not found
[warn] ::::::::::::::::::::::::::::::::::::::::::::::
[warn]
[warn] Note: Unresolved dependencies path:
[warn] org.scalaz.stream:scalaz-stream_2.10:0.7a
[warn] +- org.specs2:specs2-common_2.10:3.4
[warn] +- org.specs2:specs2-matcher_2.10:3.4
[warn] +- org.specs2:specs2-core_2.10:3.4
[warn] +- org.specs2:specs2-mock_2.10:3.4
[warn] +- com.typesafe.play:play-specs2_2.10:2.4.0-RC1 (/Volumes/Home/j.ward/projects/webjars/webjars-play/build.sbt#L13-22)
[warn] +- org.webjars:webjars-play_2.10:2.4.0-M3-2-SNAPSHOT

[Ben McCann]

Did you add the scalaz resolver mentioned in the migration guide?

resolvers += "scalaz-bintray" at "https://dl.bintray.com/scalaz/releases"




--

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

--

about.me/benmccann

[James Ward]

Thanks Ben.  That fixes it but that is pretty unfortunate for an RC to use a non-default resolver.  Any plans to proxy this to a default repo or help the scalaz folks get their stuff into Maven Central?

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

about.me/benmccann

[Kenji Yoshida]

https://github.com/scalaz/scalaz-stream/issues/258

[Sean Brady]

Super excited for this release!  Thanks everyone!

[Marcos Pereira]

Scala or Java? How did you try to do that? The pages below describes how to use the WSClient:

https://playframework.com/documentation/2.4.0-RC1/ScalaWS

https://playframework.com/documentation/2.4.0-RC1/JavaWS

HTH,

--
http://about.me/marcospereira

On Fri, Apr 24, 2015 at 8:33 PM, Nweike Onwuyali <nweikeo...@gmail.com> wrote:

Hi, I injected WSClient into my controller. I am getting a Null Pointer. Can i get the procedure of injecting WSClient into a controller?

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.

[Grzegorz Slowikowski]

Hi

I've tried to run `play-scala-intro` template with Play! 2.4.0-RC1, but it does not work.

ApplicationSpec throws:

```
[error]    Guice provision errors:

[error]   

[error]    1) Error injecting constructor, scala.tools.reflect.ToolBoxError: reflective compilation has failed: cannot initialize the compiler due to java.lang.VerifyError: scala/tools/reflect/ToolBoxFactory$ToolBoxImpl$ToolBoxGlobal

[error]      at models.DB.<init>(Unknown Source)

[error]      while locating models.DB

[error]        for parameter 0 at controllers.Application.<init>(Unknown Source)

[error]      while locating controllers.Application

[error]        for parameter 1 at router.Routes.<init>(Unknown Source)

[error]      while locating router.Routes

[error]      while locating play.api.test.FakeRouterProvider

[error]      while locating play.api.routing.Router

[error]   

```

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.

[Hossein Kazemi]

Hi,

Thanks for the great work! This is a much anticipated version!

I created a test project using RC1 with Scala. I am having some issues with the dependency injection inside actions.

In short, I have created an Authenticated(not from the helpers) action by extending ActionBuilder. In my Action I need to access one of my components using DI.

I faced two problems:

if I do this:

object Authenticated extends ActionBuilder[Request] {
  val logger = Logger(this.getClass)
  val ACCESS_TOKEN_HEADER_KEY = "X-ACCESS-TOKEN"
  @Inject() private var service: Service = null // blows up!
  override def invokeBlock[A](request: Request[A], block: (Request[A]) => Future[Result]): Future[Result] = {
    val requestToken = request.headers.get(ACCESS_TOKEN_HEADER_KEY)
    requestToken match {
      case Some(token) => {
        // get token
        service.getUserById(UUID.randomUUID())
        // Do something
      }
      case _ => {
        Future.successful(Forbidden("badd"))
      }
    }
  }
}

the "service" instance never gets injected, and I end up with a nullpointer exception.
It seems that dependency injection on the Fields do not work properly.
However, if I convert the object to a class and inject my service on the constructor like below:

class Authenticated @Inject() (service: Service) extends ActionBuilder[Request] {
  val logger = Logger(this.getClass)
  val ACCESS_TOKEN_HEADER_KEY = "X-ACCESS-TOKEN"

  override def invokeBlock[A](request: Request[A], block: (Request[A]) => Future[Result]): Future[Result] = {
    val requestToken = request.headers.get(ACCESS_TOKEN_HEADER_KEY)
    requestToken match {
      case Some(token) => {
        // get token
        service.getUserById(UUID.randomUUID())
        // DO something 
        block(request)
      }
      case _ => {
        Future.successful(Forbidden("badd"))
      }
    }
  }
}

Dependency injection happens, but then I will have problem on the controller side. I can no longer use def index = Authenticated{ }, because now I am dealing with a class. So to go around this I had to inject the action itself into my controller and use the action as below:

class Application @Inject()(authenticated: actions.Authenticated) extends Controller {
  
  def profile = authenticated {
    Ok("user profile")
  }
}

I don't like this solution as it is a bit hack-ish. To me it seems that the whole DI in play is still not mature enough. I think most of the problems stem from the fact that in scala we have object and classes and if the DI frameworks(for example Macwire and Guice here) only support constructor based DI, then defining things in Play with objects (for example Actions) will be problematic in case you want to inject something into them.

I have tried the same approach in Java, and there dependency injection works fine in the Actions on fields.

If you have any better solutions for my problem, please do help.

Regards,

Hossein

[James Roper]

Hi Hossein,

Thanks for trying the RC out and for the feedback.

What you've implemented there is most likely what all controllers are going to look like in Play 3 - a hello world controller will probably look like this:

class Application @Inject() (action: Action) {

  def index = action { req =>

    Ok("Hello world!")

  }

}

This is because all ActionBuilders (directly and indirectly) reference state, they reference state about the global configuration of the built in body parsers, they reference the http error handler, and they reference the execution context - all of these need to be dependency injected.  We haven't introduced this in Play 2.4 because we want to ease people into the change - we've reserved sweeping breaking changes for Play 3.  So at the moment, Action works as is and just references the global state.

How you address this in Play 2.4 is up to you, but here are some options:

* Concede that actions are global state things in Play 2.4 and don't dependency inject them.  So your authenticated action will get its service like this:

private def service: Service = play.api.Play.current.injector.instanceOf[Service]

The advantage of this option is that you don't have to migrate any of your actions/controllers.  The disadvantage, it's not dependency injected.

* Do exactly as you're done, in anticipation that this is how everything will be in Play 3.0.  The advantage here is that things are being done "the right way".  The disadvantage, it's a large migration task.

* Break the Scala naming conventions, and call your injected action Authenticated, eg:

class Application @Inject()(Authenticated: actions.Authenticated)

This is a compromise between the two, you have to update every controller, but you don't have to update every action in every controller.

Is there anything you think we should add to the docs to help others here?

Cheers,

James

--

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

[Grzegorz Slowikowski]

Could you help me with this problem?

Regards

Grzegorz

[Hossein Kazemi]

Hi James,

Thanks for your reply and clarification. What you explained raised some questions for me:

1- If I go with non-DI approach, using the:

private def service: Service = play.api.Play.current.injector.instanceOf[Service]

Will I get the same instance of Service as it is used everywhere else(as a singleton)?

2- If I go with the "correct approach" as I am doing now: I am injecting Service in to my AuthenticatedAction, and then injecting the AuthenticatedAction into my controller, while my controller has already is being injected with Service (I did not put this line in the example I showed you before). I have a Circle of dependencies. Isn't it bad practice?

Regarding what we can add to the documentation to help others, I was missing the piece about how to create an instance of an actor that is dependency injected:

class UserActor @Inject()(service: Service) extends Actor {
  
  override def receive: Receive = {
    case SayHello(name: String) => sender() ! "Hello," + name
  }

}

In my use-case I needed to, per request, create a new instance of my UserActor. To do that I needed to inject the Injector and use it as below:

    val userActor = system.actorOf(Props(injector.instanceOf[UserActor]), name = userId.toString)

Regards,
Hossein

[James Roper]

On 28 April 2015 at 18:56, Hossein Kazemi <mrhosse...@gmail.com> wrote:

Hi James,

Thanks for your reply and clarification. What you explained raised some questions for me:

1- If I go with non-DI approach, using the:

private def service: Service = play.api.Play.current.injector.instanceOf[Service]

Will I get the same instance of Service as it is used everywhere else(as a singleton)?

It depends on whether Service is configured to be singleton or not, which is controlled either by putting the @Singleton annotation on it, or by specifying singleton scope in your module bindings.  For more details:

https://www.playframework.com/documentation/2.4.x/ScalaDependencyInjection#Singletons

https://www.playframework.com/documentation/2.4.x/ScalaDependencyInjection#Providing-custom-bindings

2- If I go with the "correct approach" as I am doing now: I am injecting Service in to my AuthenticatedAction, and then injecting the AuthenticatedAction into my controller, while my controller has already is being injected with Service (I did not put this line in the example I showed you before). I have a Circle of dependencies. Isn't it bad practice?

That's not a circular dependency.  A circular dependency would be if Service was being injected with your controller, or with AuthenticatedAction.  Having X depend on Y, and Z depend on X and Y is not a circular dependency.

Regarding what we can add to the documentation to help others, I was missing the piece about how to create an instance of an actor that is dependency injected:

class UserActor @Inject()(service: Service) extends Actor {
  
  override def receive: Receive = {
    case SayHello(name: String) => sender() ! "Hello," + name
  }

}

In my use-case I needed to, per request, create a new instance of my UserActor. To do that I needed to inject the Injector and use it as below:

    val userActor = system.actorOf(Props(injector.instanceOf[UserActor]), name = userId.toString)

There are three approaches you could take:

1) Use Play's built in DI support for actors:

https://www.playframework.com/documentation/2.4.x/ScalaAkka#Dependency-injecting-actors

2) Manually inject service into your UserActor, rather than letting Guice instantiate it.  In that case, whatever creates the actor will have to have Service injected into it so that it can create the actor.

3) Do exactly as you've done there, by depending on an injector.

[Dominik Dorn]

A friend of mine runs into Problems when trying to run my play project under windows (I use linux):

$ sbt '~run'
[info] Loading project definition from C:\Users\root\IdeaProjects\play24project\fronte
nd-webapp\project
java.lang.NoSuchMethodError: play.PlayImport$PlayKeys$.playWatchService()Lsbt/Se
ttingKey;
        at play.sbt.forkrun.PlayForkRun$.forkConfigTask(PlayForkRun.scala:121)
        at play.sbt.forkrun.PlayForkRun$.projectSettings(PlayForkRun.scala:63)
        at sbt.Load$$anonfun$autoPluginSettings$1$1.apply(Load.scala:666)
        at sbt.Load$$anonfun$autoPluginSettings$1$1.apply(Load.scala:666)
        at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(Traversable
Like.scala:251)
        at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(Traversable
Like.scala:251)
        at scala.collection.immutable.List.foreach(List.scala:318)
        at scala.collection.TraversableLike$class.flatMap(TraversableLike.scala:
251)
        at scala.collection.AbstractTraversable.flatMap(Traversable.scala:105)
        at sbt.Load$.autoPluginSettings$1(Load.scala:666)
        at sbt.Load$.sbt$Load$$expandSettings$1(Load.scala:681)
        at sbt.Load$$anonfun$sbt$Load$$expandSettings$1$2.apply(Load.scala:682)
        at sbt.Load$$anonfun$sbt$Load$$expandSettings$1$2.apply(Load.scala:682)
        at scala.collection.IndexedSeqOptimized$class.foldl(IndexedSeqOptimized.
scala:51)
        at scala.collection.IndexedSeqOptimized$class.foldLeft(IndexedSeqOptimiz
ed.scala:60)
        at scala.collection.mutable.WrappedArray.foldLeft(WrappedArray.scala:34)

        at scala.collection.TraversableOnce$class.$div$colon(TraversableOnce.sca
la:138)
        at scala.collection.AbstractTraversable.$div$colon(Traversable.scala:105
)
        at sbt.Load$.sbt$Load$$expandSettings$1(Load.scala:682)
        at sbt.Load$.resolveProject(Load.scala:684)
        at sbt.Load$.finalizeProject$1(Load.scala:549)
        at sbt.Load$.loadTransitive(Load.scala:577)
        at sbt.Load$.loadProjects$1(Load.scala:442)
        at sbt.Load$.loadUnit(Load.scala:446)
        at sbt.Load$$anonfun$18$$anonfun$apply$11.apply(Load.scala:281)
        at sbt.Load$$anonfun$18$$anonfun$apply$11.apply(Load.scala:281)
        at sbt.BuildLoader$$anonfun$componentLoader$1$$anonfun$apply$4$$anonfun$
apply$5$$anonfun$apply$6.apply(BuildLoader.scala:91)


Adding
 PlayKeys.fileWatchService := play.runsupport.FileWatchService.sbt(2000)

to the build.sbt file did not help.

Any ideas? The only difference I've seen between my system and his (apparent from mine being linux and his windows) is that for some reason play pulls scala 2.10 down while my installation uses scala 2.11. Its especially strange as the build.sbt file specifies 2.11 by setting 

scalaVersion := "2.11.5"

Any ideas ? 

I made sure he uses sbt 0.13.8 and java 8

On Friday, April 24, 2015 at 6:49:47 AM UTC+2, james...@typesafe.com wrote:

[Marcos Pereira]

This is something that we need to add to the migration guide. Fortunately, there is already a pull request for that:

https://github.com/playframework/playframework/pull/4317

Best,

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.

[Dominik Dorn]

This is my pull request and it only fixes the documentation gap, not the issue itself on windows :/ 

The dominant error is:

java.lang.NoSuchMethodError: play.PlayImport$PlayKeys$.playWatchService()Lsbt/SettingKey;

It looks more like an issue that the signature of PlayKeys changed and an sbt-plugin (?) still tries to access the old key.

best regards,
Dominik

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Dominik Dorn
http://dominikdorn.com | http://twitter.com/domdorn
XING: https://www.xing.com/profile/Dominik_Dorn
LINKEDIN: http://at.linkedin.com/pub/dominik-dorn/66/b42/bb1/

[Ben McCann]

Hey Dominik,

I just ran "grep -r playWatchService ." on the Play source code and it didn't return any results. It seems like the project on your friend's machine is pulling in a different version of some library that's conflicting. Maybe check his $HOME/.sbt directory to see if he's specified a conflicting version of Play there? If you can test on another Windows machine that could also help narrow down if it's Windows generally or just something about his machine.

-Ben

about.me/benmccann

[Rich Dougherty]

Hi Ricardo

The values generated by the Crypto APIs have changed in Play 2.4 to use a more secure approach. See: https://www.playframework.com/documentation/2.4.x/Migration24#Crypto-APIs

The new Crypto implementation will encrypt in a different format. Crypto supports decoding both the old and new formats, but will only encode in the new format. If you want to encode in the old format for some reason then the easiest way is probably to copy the old source code (linked form the migration docs).

(This change was implemented by @tikurahul. Thanks!)

– Rich

On Sat, Apr 25, 2015 at 9:40 AM, Ricardo Franco <rmf.f...@gmail.com> wrote:

I’m updating the Silhouette to RC1 but i got problem with Crypto that is return different value

val json = """{"value":"value","expirationDate":1429928854718}"""
val c1 = Crypto.encryptAES(json, "key")
val c2 = Crypto.encryptAES(json, "key")
println(c1 == c2) // false
println(c1) // 2-Igr820+MvOvcloAi1acJEjOmaVzLOY1W/vp/CL0FR9NSVjhYvcQgmmf5bPcMlDNNkMFXZj0l5c6S+9kfytb0ig==
println(c2) // 2-FYHyup0LrS0VcEWtDrZ3GajOJ3lueKBCAvG/NbjGDS6x+5O0Z9Q9d6wm28uScQKq9rAeO4yGA9vMQ828Z6ZMFA==

Any idea?

​

--

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

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Rich Dougherty

Engineer, Typesafe, Inc

@richdougherty

[James Roper]

Also Ricardo,

To explain why they are different on repeated invocations of encrypting the same String, previously Play was using a rather insecure cipher block mode called ECB.  One consequence of ECB is that output values are deterministic, encrypting the same input will always result in the same output.

We switched Play to use CTR, which uses a random nonce to seed a cryptographically secure pseudorandom number generator, resulting in a different output value every time you encrypt the same string - note though that when you decrypt these different values, you will always get the same value.  CTR is much more secure than ECB, which is why we did this.  However, if you want to switch Play back to use ECB, you can do that by setting the transformation in application.conf:

play.crypto.aes.transformation = "AES/ECB/PKCS5Padding"

If you do this, you'll get deterministic output values, however as Rich said, the format has changed.

Regards,

James

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Igmar Palsenberg]

 

This is my pull request and it only fixes the documentation gap, not the issue itself on windows :/ 

The dominant error is:

java.lang.NoSuchMethodError: play.PlayImport$PlayKeys$.playWatchService()Lsbt/SettingKey;

It looks more like an issue that the signature of PlayKeys changed and an sbt-plugin (?) still tries to access the old key.

Wipe your Ivy cache. It has helped me with these kind of problems.

Igmar 

[James Roper]

Dominik,

Try

rm -r project/target project/project/target

And see if that helps.

[Grzegorz Slowikowski]

No, I don't know, how to solve it.

On Apr 30, 2015 22:46, "Johan Dahlberg" <jo...@dahlberg.co> wrote:

Have you solved the error? I have the same error.

/Johan

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.

[Dominik Dorn]

I told my friend to delete the following directories/contents of these, and it worked for him:

~/.sbt/*
project/target
project/project/target
target/ 

On Thu, Apr 30, 2015 at 10:46 PM, Johan Dahlberg <jo...@dahlberg.co> wrote:

Have you solved the error? I have the same error.

/Johan

Den lördag 25 april 2015 kl. 12:06:03 UTC+2 skrev Grzegorz Slowikowski:

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Dominik Dorn
http://dominikdorn.com
http://twitter.com/domdorn

Skripten, Mitschriften, Lernunterlagen, etc. findest Du auf http://www.studyguru.eu !

[James Roper]

Do you mean when 2.4.0 final is released?  When we release an RC, and it has survived a week with no major issues raised against it, then 2.4.0 will be released.

On 7 May 2015 at 17:33, Christian Schmitt <c.sc...@briefdomain.de> wrote:

Hi, do you know when there will be a release version.

--

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

--

[Konstantin Nikiforov]

Thank you for your work. Successfully migrated one fat project from M3.

I want to notify developers & M3-users about changes in i18n since M3:

Changes in application.conf:
- play.modules.i18n.langs = "ru-RU,en-US"
+ play.i18n.langs = ["ru-RU", "en-US"]

This change only for M3 -> RC1 migration with i18n. If M3-users keep stay with play.modules.i18n.langs config key, conf/messages.* will be silently ignored.


пятница, 24 апреля 2015 г., 7:49:47 UTC+3 пользователь james...@typesafe.com написал:

[Igmar Palsenberg]

 

Do you mean when 2.4.0 final is released?  When we release an RC, and it has survived a week with no major issues raised against it, then 2.4.0 will be released.

Testing seems broken in RC1 : All JUnit annotations give a compile error, and I had to manually add JUnit to the classpath  to resolve this.

Igmar

[Naftoli Gugenheim]

On Mon, May 4, 2015 at 4:34 PM Dominik Dorn <domini...@gmail.com> wrote:

I told my friend to delete the following directories/contents of these, and it worked for him:

~/.sbt/*

Not everyone can delete ~/.sbt/* --- often people put global customizations in there.

Assuming you're only using sbt 0.13.x, the following should be safe (and suffice):

~/.sbt/boot

~/.sbt/0.13/target

~/.sbt/0.13/plugins/target

~/.sbt/0.13/plugins/project/target

Possibly: ~/.sbt/0.13/staging

If you have fish you could just rm -rf ~/.sbt/**/target