DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Contexts, Decade in.. ?

Contexts, Decade in.. ?

Rob Williams user avatar by
Rob Williams
·
May. 25, 11 · Java Zone · Interview
Like (0)
Save
Tweet
3.22K Views

Join the DZone community and get the full member experience.

Join For Free

DI didn‘t invent ‘The Hollywood Principle.‘ So don‘t call me, I‘ll call you. Yeah that‘s great. That tells us that the container will compose the context, but is that it? The context itself is still just whatever all you need at any given time to do some unspecified amount of work.

Last week, we were finishing some logic in a 4 or 5 panel wizard that required us to resubmit orders many times. (You‘ve seen this movie before..) The restart was nothing, I was actually enjoying that part. Watching my pair partner fill out the registration like 50x made me completely crazy. While I was in the sidecar, I started thinking about an escape valve…

One of the great things about JSF is that the binding is pretty straightforward, and the framework does a lot of the other work (marshal/unmarshal, convert/validate, etc.) So it dawned on me that all I really needed was a way to stipulate a different factory for the abstraction that the wizard was binding, and then I would feed up an instance with the fields filled out so we could just click through the panels. Here‘s the sick part: a decade into the DI revolution, that‘s not only not a simple thing to do, it‘s dizzyingly stupid how much flapping is required to get this emu off the ground.

Checkout this blog post . There‘s nothing wrong with it, it‘s pretty interesting and the author seems to be pretty excited about it, but dear god, all the crap that is needed to sneak an alternate implementation is really nauseating.

While I was scouting around for the right way to do this with CDI, I mentioned this to mert, and he mentioned that JSF2 has stages. Of course ended up on the Adam Schwartz blog post I‘ve seen 20x. Sounds cool, or looks cool, but that‘s not going to do what I need, it might make it easy. Took some humor in the fact that Matthias wanted to make a system property out of it; kind of typified the madness at the center of this: the bean container wants to give you declarative powers, then the annotations take them back and put them back into compile time realm, ultimately, all this time later, the central trope here (Liskov‘s substitution principle slubbed through the usual DP slats: prototype, singleton, etc.) is still unable to bridge this gap easily.

How should this work? I guess what I am thinking about doing now is making a listener on the container start, then looking at the hostname. If it‘s localhost, I would light up a bunch of Development factories. How? I‘d probably have to do some goofy interceptor-based substituter like in the blog post, which is total madness, but of course, we don‘t want the code annotated with a bunch of development requirements that have nothing to do with the model. What would be best would be if the concept of context was a bit more sophisticated. Not a jumble of chained black magic like the classloader mechanism, but if there were a way to define the contexts that are nested, and triggered by certain environmental conditions, then the factories associated with those contexts would naturally just come to the fore.

Update: Starting to look like what I‘ll do is look for the hostname and then trigger a method if it is localhost that will allow me to load anything I want to into a development environment (kind of like a PostConstruct) but using AfterBeanDiscovery.addBean() with an Alternative. I had thought one other possibility might have been to make an @Alternative implementation of the abstraction that also had a qualifier on it that would not be true (and hence would prevent the alternative from being loaded if we were not in a dev environment).

 

From http://www.jroller.com/robwilliams/entry/contexts_decade_in

Factory (object-oriented programming) Container POST (HTTP) Blog Abstraction (computer science) Binding (linguistics) Implementation Concept (generic programming) Spring Framework

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Your Old Laptop Is Your New Database Server
  • Stupid Things Orgs Do That Kill Productivity w/ Netflix, FloSports & Refactoring.club
  • How the TypeScript ReturnType Works
  • Why to Implement GitOps into Your Kubernetes CI/CD Pipelines

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo