JBossDeveloper

Gavin King wrote on Nov 12, 2009 05:44:

[Guice] still [doesn't] support a solution to the problem of cross-scope injection
It's a literally true statement,

The statement is not true. In Guice, if you want to inject RequestScopedFoo into SessionScopedBar, you inject Provider<RequestScopedFoo> into SessionScopedBar and call get() on the provider whenever you want to retrieve RequestScopedFoo from the request. CDI takes this one step further and injects a proxy that calls get() automatically on every method invocation and delegates the call. That shaves off some characters, but it has all of the drawbacks I mentioned above and apparently in the TSS thread (thanks for the reminder).

Oh, my apologies Bob, I did not realize that the service locator pattern (which is what Provider is) now counts as injection.

Wow, all this new terminology for me to learn!

Oh and I notice you still don't like talking about the issue of @ApplicationScoped injected into @SessionScoped. What happens when the session gets serialized? What does Guice do?? It's apparently one of the great mysteries of life. No-one knows the answer. Philosophers can speculate.

Gavin King wrote on Nov 12, 2009 18:28:

Oh, my apologies Bob, I did not realize that the service locator pattern (which is what Provider is) now counts as injection. Wow, all this new terminology for me to learn!

Actually, this isn't the service locator pattern. With the service locator pattern, you pass an identifier at run time to the lookup method. Provider.get() takes no arguments; you select the implementation when you inject the provider, not with a run time argument. The provider-based approach has a couple advantages over a service locator. Namely, it's more efficient and it can be verified at build time.

Bob, you're wrong. The usual service locator pattern looks like this:

ServiceLocator.get(Foo.class)

The identifier you're talking about is a typesafe class object, which can be verified at build time.

It's no different to Provider at all. It's just the pre-generics version of Provider.

I should be clearer. It looks like:

Foo foo = ServiceLocator.get(Foo.class)

Some people indirected that a little more:

Foo foo = ServiceLocator.instance().get(Foo.class)

Anyway, it was typesafe.

Now, I don't know how you used to write your service locator, but that's what those of us with a clue used to do. :-)

Arbi Sookazian wrote on Nov 12, 2009 17:22:

Stuart Douglas wrote on Nov 12, 2009 05:14:


I don't get why people seem to think that transactions and security are things that can just sort of be stuck on later. When I am writing code I usually know exactly what the transactional behavior should be, and expressing that with an annotation in the actual code makes a lot more sense to me than expressing it in an XML document somewhere else entirely.

You're right, it's more natural with annotations.  The point is that when I took my Spring training, the instructor pointed out in an example project that you can literally add tx, security or logging support via xml configurations and not change or add a line of code in your classes.  That seems convenient but you're right, it's less natural to do it all at the end that way...

I it is great how Java has come from multiple incompatible XML based deployment descriptors, to a portable non-standard XML descriptor (Spring) to portable Annotations (Seam/Spring) to standard annotations (Weld) to deal with transactions (and AOP, Interceptors and whatever other epicycles are added to make transaction handling simpler).

But when I think that in EOF all I had to do was: editionContext.saveChanges() and all was automatically handled (validation, transactions and whatnot) I wonder how many years I am going to have to wait for that to become mainstream... (yes, I know, I should be ashamed of my lazyness ;-)

Gavin King wrote on Nov 12, 2009 18:34:

Oh and I notice you still don't like talking about the issue of @ApplicationScoped injected into @SessionScoped. What happens when the session gets serialized? What does Guice do?? It's apparently one of the great mysteries of life. No-one knows the answer. Philosophers can speculate.

I explained this in the TSS thread you linked to. We prefer to use static injection in this case, i.e. SessionScopedBar keeps a static reference to ApplicationScopedTee. We actually couldn't take the CDI approach and serialize the proxy because Guice supports an arbitrary number of injectors. We have no way to tell which injector to use when we deserialize the proxy. Of course, we could enable the user to tell us which injector to use (I think this is what Spring does), but the overall result would be a lot messier than just using a static field. You'll cross this bridge once CDI supports more than one injector per deployment unit. As an added bonus, by not serializing the application-scoped reference at all, we don't have the serialized proxy state bloating our sessions.

I actually discourage users from using serializable sessions for anything but a minimal amount of immutable data. Sessions have inherent concurrency problems (like the container serializing your objects while you're changing them in a concurrent request). Sessions expire--what if the user wants to come back tomorrow and pick up where they left off? Serializable objects are notoriously difficult to evolve in a compatible way, so you end up blowing away your sessions every time you upgrade your code (we use rolling deployments to mitigate this problem). You're much better off keeping everything in a database. Yay JPA!

Gavin King wrote on Nov 12, 2009 18:47:

Bob, you're wrong. The usual service locator pattern looks like this:
ServiceLocator.get(Foo.class)
The identifier you're talking about is a typesafe class object, which can be verified at build time.
It's no different to Provider at all. It's just the pre-generics version of Provider.

Is ServiceLocator.get(someClass()) statically checkable?

2) I'm not going to argue with you about what you're not sold on (adding XML for AOP in Spring is not practical) b/c I don't have extensive experience with it, but I'm pretty sure I saw it with my own eyes a few years ago in that Spring training (don't recall if it was logging or tx's or what).

You saw a toy example with two beans and a logging interceptor. I'm not talking about toys, Arbi, I'm talking about industrial software development with thousands of classes and tens of developers.

an example of Spring AOP for logging interceptor:

I don't know why you keep quoting the code examples at us. We know what an interceptor looks like. If you want to see what it looks like in Weld, read the examples in the CDI spec or Weld documentation.

The code is much cleaner than that Spring XML you just spammed us with.

Note here the finer level of granularity in terms of execution of advice on method calls (before and after advice).  Whereas in EJB3 we simply have the @AroundInvoke AFAIK.

OK, now that's just nuts dude. Java has a whole built-in language feature for doing before, after returning and after throwing. It's called try, catch, finally. I know the Spring guys like to invent their own shit, but reinventing basic features of the language? Really?

Ok, that article seems way too over-complicated for such a simple implementation of a cross-cutting concern that can be implemented more cleanly/easily with Seam/EJB3 (and maybe even better with CDI?)

Hrm, maybe? Who knows? How could we possibly find out? Perhaps if someone bothered to read the spec, they could tell us all what CDI can do?

We prefer to use static injection in this case

Ahah, so the truth comes out. And if we have a ref from a @CoversationScoped object to a @SessionScoped object?

Oh. Ooops. You're fucked. Back to Provider. Awesome. Let's look away now and pretend nothing happened.

(Oh and let's also set aside the problem of static injection in a multi-application environment with library jars potentially shared between different applications and different modules, since I believe these problems are at least semi-solvable.)

I actually discourage users from using serializable sessions for anything but a minimal amount of immutable data.

OK, whatever. I'm perfectly happy if CDI has a good solution for session and conversation scope and Guice doesn't.

But what I can't figure out is why, if you discourage the use of session scope, you would even care what CDI says about them.

CDI already supports @Dependent and @Singleton objects without proxies (they are pseudo-scopes). We could easily add a request pseudo-scope - indeed I plan to write a portable extension for that, since it's useful with JPA entities.

So the only case where these supposedly evil, evil proxies start to appear is with these servlet scopes that you apparently discourage the use of.

You're much better off keeping everything in a database.

Right, in the least scalable tier of the application. Great.

Can we end this stupid discussion now, please? Every time we have it, I discover more little wrinkles and programming limitations in Guice.

Can we please have a conversation without the snideness?

Gavin King wrote on Nov 12, 2009 19:24:

We prefer to use static injection in this case
Ahah, so the truth comes out. And if we have a ref from a @CoversationScoped object to a @SessionScoped object?

Oh. Ooops. You're fucked. Back to Provider. Awesome. Let's look away now and pretend nothing happened.

We store conversation state in the session, so from a serialization standpoint, it's OK to have references in either direction.

But what I can't figure out is why, if you discourage the use of session scope, you would even care what CDI says about them.

I don't care. I only chimed when you said something along the lines of Guice still doesn't support scope proxies, as if Guice would one day catch up to CDI and support them. I clarified by saying Guice will never support scope proxies; I consider this a feature.

You're much better off keeping everything in a database.
Right, in the least scalable tier of the application. Great.

We run Guice in Gmail, Wave, AdWords, YouTube, etc. I think we know a little bit about scalability. :-)

Can we end this stupid discussion now, please? Every time we have it, I discover more little wrinkles and programming limitations in Guice.

What did you discover exactly?

Also, you didn't answer my question: Is ServiceLocator.get(someClass()) statically checkable?

Arbi Sookazian wrote on Nov 12, 2009 19:21:

So how will the HttpSessions be replicated to nodes in a cluster for seamless failover, for example?

To be clear, I recommended against using HttpSession at all.

What apps have you used that allow user to come back tomorrow to complete processing a shopping cart, for example?

Amazon. All apps should. Why would you throw away a user's data? That's hostile to your users. Is disk space so scarce?

Unless you turn off SFSB passivation and turn off session timeout (typically 30 min default) in web.xml or server specific xml file.  In which case you'd better have a very robust cluster that can handle that much load and memory requirements...  Probably won't scale well at all...

Again, this doesn't help you when it comes time to upgrade your servers, unless you evolved your serializable types in a compatible fashion, something that's next to impossible to do reliably in a non-trivial application, not to mention very difficult to test.