Ask questions and see you at 6th April 6.PM. CET: http://www.ustream.tv/channel/adambien
See also the airhacks archives airhacks.tv and subscribe to the airhacksnews.com
What is the best way to achieve a singleton JPA @entity? I find I often I want to create a singleton object which holds runtime configuration data, configurable within the application itself, and persistently stored within the JPA environment for that application. In order to maintain that only one ApplicationConfiguration will ever exist within the application, I have to jump through hoops for all CRUD operations within my DAO layer and play tricks with the @id (checking if @entity exists, then remapping the CxUD with the getId() of the originally persisted entity, yuck). Would you please recommend a strategy for a JPA @entity which follows @singleton semantics. Thank you!
Are cross-view (cross-rectangle) Presenter something valuable? Did you ever miss that?
In JEE application I used to freedom in EJB assembly, for example:
I have 3 EJB A,B,C. I can freely assembly other EJBs:
@stateless class AddressBean {
@Inject A a;
@Inject B b;
}
@stateless class PaymentBean {
@Inject B b;
@Inject C c;
}
In JavaFx view is constructed in FXML with rectangles. For example one top rectangle is attendeeinput.fmxl and bottom rectangle is workshops.fxml. And bottom rectangle has inside other rectangle day.fxml. That is OK.
What is hard to accept to me is that Presenter is tied to rectangles. I would like to have freedom with Presenter assembly, i would like to inject by @FMXL gui components from many rectangles.
For example if checkbox from top rectangle is checked then textfield from bottom rectangle is disabled. It will be natural to me to have a dedicated Presenter, not tied to any rectangle, with injected by @FXML checkbox from top and textfield from bottom view.
Conclusion: I want Presenter freedom. I didn't found the freedom in JavaFX so checked afterburner.fx. but there isn't also.
My questions:
Do you think there is value in having a JDBC driver wrapper which populates its configuration parameters (e.g. jdbc.url) from a distributed configuration management system like etcd (by CoreOS)? The idea being that a customer would stand up many instances of a JavaEE server, probably through Docker, and configure the database endpoint through etcd. Then the database could be dynamically migrated and update the etcd configuration. This might allow database migration without restarting all web layer microservices. Is this pathologically dangerous? Is there some alternative to this? Thank you!