Re: EJB JNDI based on execution environment
On Mon, 30 Mar 2015 06:27:13 -0300, Adam X wrote: 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 Have you seen http://tapestry.apache.org/configuration.html#Configuration-SettingExecutionModes? This way, you can segregate environment-specific stuff to different module classes, just one of them being used and loaded after AppModule, depending on web.xml or JVM arg. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: EJB JNDI based on execution environment
Okay - implemented environmental property loader translation mechanism to
symbol contribution. All works well. For completeness of this thread, in a
nutshell:
/**
* Valid values for deploy environment hosting a running code. One of these
* values is passed as JVM arg via {@link
JvmArgugments#DEPLOY_ENVIRONMENT}.
* If none provided, a default of {@link #local} is used.
*
* @author AdamX
*/
public enum DeploymentEnvironment {
production, readiness, development, local
}
AppModule.java:
public static void contributeApplicationDefaults(
MappedConfiguration configuration,
@ClasspathProvider AssetFactory classpathAssetFactory) {
// relevant call below:
Resource rootResource = classpathAssetFactory.getRootResource();
String rootPath = rootResource.toURL().getPath(); // root of the
source
loadDeployEnvironmentContributions(rootPath, configuration);
}
private static void loadDeployEnvironmentContributions(
String aFilePath,
MappedConfiguration aConfiguration) {
// implemented pseudo from my earlier thread post
}
Now, depending on -Dourapp.deploy-environment relevant contribution symbols
are added:
[DEBUG] pl.ourapp.services.AppModule checking for
[-Dourapp.deploy-environment]
[INFO] pl.ourapp.services.AppModule detected [-Dourapp.deploy-environment]
= [local]
[INFO] pl.ourapp.services.AppModule deploy environment is [local]; loading
contribution symbols from: /home/adamx/workspace/ourapp/target/classes/
[INFO] pl.ourapp.services.AppModule [ejb.local] is contributing:
oo.ejb-naming-factory =>
org.apache.openejb.client.RemoteInitialContextFactory
[INFO] pl.ourapp.services.AppModule [ejb.local] is contributing:
oo.ejb-host => ejbd://127.0.0.1:4201
[INFO] pl.ourapp.services.AppModule [ejb.local] is contributing:
oo.jndi.registrationdao => RegistrationDaoRemote
Thanks
On Mon, Mar 30, 2015 at 1:47 PM, Adam X wrote:
> 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 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
>> >> relia
Re: EJB JNDI based on execution environment
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 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 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
> 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
Re: EJB JNDI based on execution environment
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 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 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 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/
>>
>>
Re: EJB JNDI based on execution environment
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 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 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
>
>
>
Re: EJB JNDI based on execution environment
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 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 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
>
Re: EJB JNDI based on execution environment
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 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
