What I mean we do not want have as tightly coupled code with things like EjbProviderEnum and BusinessServicesLocator with if-then for each container's JNDI format - and we'd like to keep it this way. Rather we would like to externalize these things (JNDIs, idealy into property files somehow translated into Tapestry symbols so they're easily injectable).
Obviously one container tie-in that seems unavoidable is InitialContext jar, for instance in case of OpenEJB: openejb-client-XXX.jar but other than that org.apache.openejb.client.RemoteInitialContextFactory and equivalents for other containers are externalized. So seems to me that it's either something like jumpstart with some clever jndi logic or simple externalization to property file ala pseudo in my earlier post? But my question On Mon, Mar 30, 2015 at 12:06 PM, Geoff Callender < geoff.callender.jumpst...@gmail.com> wrote: > I'm not sure I understand your question, but see if > BusinessServicesLocator in the example is what you're after: > > > http://jumpstart.doublenegative.com.au/jumpstart7/examples/state/atejb > > BTW, this isn't just theoretical. I develop with OpenEJB but usually > deploy in JBoss - eg. the JumpStart demo above is running in JBoss. > > On 30 Mar 2015, at 8:27 pm, Adam X <vbgnm3c...@gmail.com> wrote: > > > We have a different way of hooking up EJBs, and it and works great - > that's > > not the issue. Our EJBs are further decoupled from Tapestry that what > > Jumpstart has done and we prefer to keep it this way. We just need a way > of > > telling tapestry that for this environment we have a this set of ejb > > properties, for that another. That's all. > > > > So far I am leaning with introducing another loader mechanism that > > transfers properties into configuration symbols. In pseudo, something > like > > this: > > > > read exec environment (prod, read, dev, local) > > detect all files with above extension (.prod .read .dev .local) > > read properties from every file > > contribute key as symbol, value as value > > > > Above takes care for our EJB situation (ejb.prod | ejb.read | ejb.dev | > > ejb.local) but also other symbols that may be needed in the future (I > don't > > know what, maybe cms or whatever etc) > > > > Geoff - so how does -Djumpstart.ejb-provider identifies context url and > all > > the jndis? I see your example uses OpenEJB. In our app, production, > > readiness and dev environments will be on jboss, but local environment > may > > be OpenEJB, GlassFish or JBoss depending on what the consultant chooses. > > > > > > On Mon, Mar 30, 2015 at 11:07 AM, Geoff Callender < > > geoff.callender.jumpst...@gmail.com> wrote: > > > >> For T5.4: > >> http://jumpstart.doublenegative.com.au/jumpstart7/examples/state/atejb > >> > >> Soon I'll modify EJBProviderUtil to read a system property provided at > >> runtime (eg. -Djumpstart.ejb-provider=OPENEJB_4_LOCAL), because it's > >> getting too hard to keep EJBProviderUtil's detection technique working > >> reliably. > >> > >> public static EJBProviderEnum detectEJBProvider(Logger logger) { > >> EJBProviderEnum ejbProvider = null; > >> > >> String ejbProviderStr = null; > >> > >> try { > >> ejbProviderStr = System.getProperty(PROPERTY_EJB_PROVIDER); > >> > >> if (ejbProviderStr == null) { > >> throw new IllegalStateException("System property \"" + > >> PROPERTY_EJB_PROVIDER > >> + "\" not found. Please set it to one of: {" + getAllowedValuesAsStr() + > >> "}."); > >> } > >> > >> ejbProvider = EJBProviderEnum.valueOf(ejbProviderStr); > >> } > >> catch (IllegalStateException e) { > >> throw e; > >> } > >> catch (SecurityException e) { > >> throw new IllegalStateException("Failed to get system property \"" + > >> PROPERTY_EJB_PROVIDER + "\": " + e); > >> } > >> catch (Exception e) { > >> throw new IllegalStateException("Found system property \"" + > >> PROPERTY_EJB_PROVIDER + "\" equals \"" > >> + ejbProviderStr + "\", expected one of: {" + getAllowedValuesAsStr() + > >> "}."); > >> } > >> > >> return ejbProvider; > >> } > >> > >> private static String getAllowedValuesAsStr() { > >> String valuesStr = ""; > >> > >> EJBProviderEnum[] values = EJBProviderEnum.values(); > >> > >> for (EJBProviderEnum ejbProviderEnum : values) { > >> valuesStr += "\"" + ejbProviderEnum.name() + "\", "; > >> } > >> > >> return valuesStr.substring(0, valuesStr.lastIndexOf(",")); > >> } > >> > >> Geoff > >> > >> On 30 Mar 2015, at 7:43 pm, Chris Mylonas <ch...@opencsta.org> wrote: > >> > >> http://jumpstart.doublenegative.com.au/jumpstart/ > >> > >> & > >> > >> http://jumpstart.doublenegative.com.au/jumpstart/examples/state/atejb > >> > >> Download jumpstart and have a look how Geoff has done it. > >> > >> > >> > >> > >> > >> > >> On Mon, 30 Mar 2015 19:34:29 +1100, Adam X <vbgnm3c...@gmail.com> > wrote: > >> > >> Hi, > >> > >> I have a different JNDI lookup depending on exec env. I have an > AppModule > >> with EJB sub: > >> > >> @SubModule(EjbModule.class) > >> AppModule > >> > >> And my EJB mod does all the EJB plumbing building the context and > >> delegating the looking up of EJBs to EjbLocatorModule. As far as > building > >> my beans I would like to inject JNDI into my EJB builder methods as a > >> symbol: > >> > >> @SubModule(EjbLocatorModule.class) > >> EjbModule { > >> // builds EjbContext and stuff > >> } > >> > >> EjbLocatorModule.java: > >> > >> public RegistrationDaoRemote buildRegistrationService( > >> @InjectService("EjbContext") Context aEjbContext, > >> @Inject @Value("${ejb.jndi.dao.registration}") String jndi) > >> { > >> // remote EJB dao lookup > >> } > >> > >> So the symbol ${ejb.jndi.dao.registration} is different depending on > >> execution environmnet (prod, readiness, dev, local) > >> > >> How it's best done in Tapestry? > >> > >> * if-then-else in a single contribution method testing -D JVM arg? > (ugly) > >> * different -D exec mode and different modules ? (will the contribution > >> load before submodule of the app module will) ? > >> * introduce another property file with a manual lookup? > >> > >> Or yet a better solution? Please advise. > >> > >> Adam > >> > >> > >> > >> -- > >> Using Opera's mail client: http://www.opera.com/mail/ > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > >> For additional commands, e-mail: users-h...@tapestry.apache.org > >> > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
