I've been trying to inject an EJB into a JAX-RS resource via InitialContext()lookup() getting the following exception:
<javax.naming.NameNotFoundException: While trying to look up
comp/env/AServiceLocal
in /app/webapp/wcc/1377099157.; remaining name 'comp/env/AServiceLocal'>
My lookup in resource constructor:
try {
initialContext = new InitialContext();
String jndiSubcontext = "java:comp/env/";
aService = (AServiceLocal) initialContext.lookup(jndiSubcontext+AServiceLocal.class.getSimpleName());
eSService = (ESServiceLocal) initialContext.lookup(jndiSubcontext+ESServiceLocal.class.getSimpleName());
eService = (EServiceLocal) initialContext.lookup(jndiSubcontext+EServiceLocal.class.getSimpleName());
} catch (NamingException e) {
e.printStackTrace();
}
Here's the file structure taking into account that they are all maven projects:
global
|
--shared
|
|---src/main/java/com/x/y/z/AServiceLocal.java (ejb)
|
--war-project
|
|--src/main/java/comm/x/y/z/TheResource.java (jax-rs)
There are more maven projects related and they are all maven-configured through the global project in a hierarchical way.
There is also a resource in the same project as war-project that also performs lookups to the shared project and they do work.
I don't understand what the problem is.
edit
After adding ejb-local-ref to deployment descriptor:
<ejb-local-ref>
<ejb-ref-name>AServiceLocal</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local>com.x.y.service.AdminXProfileServiceLocal</local>
<ejb-link>shared.jar#AdminXProfileService</ejb-link>
</ejb-local-ref>
I get the following error:
[J2EE:160101]Error: The ejb-link "shared.jar#AService"
declared in the ejb-ref or ejb-local-ref "AServiceLocal"
in the application module "xyz-99.1.0-SNAPSHOT.war" could not be
resolved. The target EJB for the ejb-ref could not be found. Ensure
that the link is correct.
The jar shared.jar is a dependency of the war project, but it seems that location is not correct. Must I add the packages also to the ejb-link ?
Something like: <ejb-link>shared.jar#com.x.y.ServiceImpl</ejb-link>
I aslo need to point out that there is a mix of hk2,cdi and lookups as part of the injection due to the fact the project is quite old and also it was migrated to weblogic 12c version recently so normal #Inject or #EJB don't appear to be working.
If I take into account all the variables I am seeing like Maven, project structure, JNDI lookup etc... the best way is to add an entry in the web.xml of the war project referencing your ejbs.
<ejb-local-ref>
<ejb-ref-name>ejb/adminXProfileService</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local>com.myapp.ejb.AdminXProfileServiceLocal</local>
<ejb-link>YourEJBLibrary.jar#adminXProfileService</ejb-link>
</ejb-local-ref>
Then in your lookup you simply look for:
contenxt.lookup("java:comp/env/ejb/adminXProfileService");
Related
Running
val myAvroObject = MyAvroObject.newBuilder()
results in a compilation error:
Cannot access class 'MyAvroObject.Builder'. Check your module classpath for missing or conflicting dependencies
I am able to access other MyAvroObject variables. More precisely, methods such as
val schema = MyAvroObject.getClassSchema()
val decoder = MyAvroObject.getDecoder()
compiles fine. What makes it even stranger is that I can access newBuilder() in my test/ folder, but not in my src/ folder.
Why do I get a compile error when using newBuilder()? Is the namespace of the avro-schema used to generate MyAvroObject of importance?
Check your module classpath generally means, that your dependencies (which you didn't provide) are messed up. One of them should read implementation instead of testImplementation, in order to have the method available in the main source-set, instead of only the test source-set - but this may well have to do with the input classes, the output location of generated classes, or annotations alike #VisibleForTesting (just see what it even generates). Command gradlew can also list the dependencies per configuration. The builder seems to be called org.apache.avro.SchemaBuilder... there's only avro-1.11.0.jar & avro-tools-1.11.0.jar. With the "builder" design pattern, .newBuilder() tries to return inner class Builder.
had the same problem today and was able to solve it by adding the following additional source folder
<sourceDir>${project.basedir}/target/generated-sources/avro</sourceDir>
to the kotlin-maven-plugin.
My route looks like below -
#Override
public void configure() throws Exception {
from("kafka:adapterTopic")
.to("rest://post:gatewayinbound-dev11.devsite.com");
}
I have tried with this as well,
.to("rest:post:gatewayinbound-dev11.devsite.com");
and this as well,
restConfigutation().host("gatewayinbound-dev11.devsite.com");
from("kafka:adapterTopic")
.to("rest:post:provideStatus/");
I have tried with camel-rest-starter dependency in the classpath and without it as well.
I have tried putting camel-rest instead of camel-rest-starter in the pom.
But nothing is making the exception go away, below is the stacktrace-
{"timestamp":"2020-04-21 18:17:45.327","severity":"ERROR","class":"org.springframework.boot.SpringApplication","crId":"","msg":"Application run failed","exception":"org.apache.camel.RuntimeCamelException","cause":"org.apache.camel.FailedToCreateRouteException: Failed to create route route10 at: >>> To[rest:post:gatewayinbound-dev11.devsite.com] <<< in route: Route(route10)[[From[kafka:adapterTopic]] -> [To[rest:... because of Failed to resolve endpoint: rest:\/\/post:gatewayinbound-dev11.devsite.com due to: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'rest-configuration' defined in class path resource [org\/apache\/camel\/model\/rest\/springboot\/RestConfigurationDefinitionAutoConfiguration.class]: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.apache.camel.spi.RestConfiguration]: Factory method 'configureRestConfigurationDefinition' threw exception; nested exception is java.lang.IllegalArgumentException: Cannot configure option [useXForwardHeaders] with value [true] as the bean class [org.apache.camel.spi.RestConfiguration] has no suitable setter method, or not possible to lookup a bean with the id [true] in Spring Boot registry"
Please help me here. Looking at the examples at Camel's website it looks quite easy to configure a rest producer endpoint but for me it has been very difficult.
Edit-
As Rest component is part of camel-core, I was using camel-core-2.22.1.
Then as suggested by Raúl Cancino, I tried this as well-
to("rest:post:provideStatus?host=gatewayinbound-dev11.devsite.com:443")
please try the following uri format on your to(), as a starting point:
to("rest:post:provideStatus?host=gatewayinbound-dev11.devsite.com:443")
then you can switch to rest configuration
restConfiguration().host("gatewayinbound-dev11.devsite.com:443");
also, using camel-http this would be:
.setHeader(Exchange.HTTP_METHOD,constant(org.apache.camel.component.http.HttpMethods.POST))
.to("https:gatewayinbound-dev11.devsite.com/provideStatus?bridgeEndpoint=true")
Hope it works for you
The problem was with the version of camel-core library my applcation was using (as transitive dependency), when I switched to camel-core-2.24.2 the problem got resolved.
I compared org.apache.camel.spi.RestConfiguration classes from both versions of camel-core, 2.22.1 and 2.24.2 and found that property useXForwardHeaders was missing in older version.
When using Kotlin's Script Engine, trying to import packages or use any class throws an "unresolved reference"
javax.script.ScriptException: error: unresolved reference: mrpowergamerbr
fun loritta(context: com.mrpowergamerbr.loritta.commands.CommandContext) {
^
This doesn't happen when running the class within IntelliJ IDEA, however it does happen when running the class on production.
While this YouTrack issue is related to fat JARs, this also can happen if you aren't using fat JARs (loading all the libraries via the startup classpath option or the Class-Path manifest option)
To fix this, or you can all your dependencies on your startup script like this:
-Dkotlin.script.classpath=jar1:jar2:jar3:jar4
Example:
java -Dkotlin.script.classpath=libs/dependency1.jar:libs/dependency2.jar:yourjar.jar -jar yourjar.jar
Or, if you prefer, set the property via code, using your Class-Path manifest option.
val path = this::class.java.protectionDomain.codeSource.location.path
val jar = JarFile(path)
val mf = jar.manifest
val mattr = mf.mainAttributes
// Yes, you SHOULD USE Attributes.Name.CLASS_PATH! Don't try using "Class-Path", it won't work!
val manifestClassPath = mattr[Attributes.Name.CLASS_PATH] as String
// The format within the Class-Path attribute is different than the one expected by the property, so let's fix it!
// By the way, don't forget to append your original JAR at the end of the string!
val propClassPath = manifestClassPath.replace(" ", ":") + ":Loritta-0.0.1-SNAPSHOT.jar"
// Now we set it to our own classpath
System.setProperty("kotlin.script.classpath", propClassPath)
While I didn't test this yet, in another unrelated answer it seems you can also supply your own classpath if you initialize the KotlinJsr223JvmLocalScriptEngine object yourself (as seen here)
We have a custom build tool which is dependent on the ivy functionality to resolve dependencies. The configuration of the dependencies is not an ivy.xml file, but a custom configuration that allows for.. well, irrelevant. The key is that we're using ivy programmatically.
Given a dependency (group id, artifact id, version), we create a ModuleRevisionId:
ModuleRevisionId id = ModuleRevisionId.newInstance(orgName, moduleName, revisionName);
followed by a ModuleDescriptor. This is, I'm guessing, where I'm not convincing enough to inform ivy that I want both the target library jar file as well as the sources. I'm just not sure what a DependencyConfiguration is vs. just a 'configuration' when creating a ModuleDescriptor.
DefaultModuleDescriptor md
= new DefaultModuleDescriptor(
ModuleRevisionId.parse("org#standalone;working"),
"integration",
new java.util.Date());
DefaultDependencyDescriptor mainDep
= new DefaultDependencyDescriptor(id, /* force = */ true);
mainDep.addDependencyConfiguration("compile", "compile");
mainDep.addDependencyConfiguration("compile", "sources");
md.addDependency(mainDep);
md.addConfiguration(new Configuration("compile"));
md.addConfiguration(new Configuration("sources"));
Nor do I really understand the above vs. RetrieveOptions vs. ResolveOptions.
I need a drink.
Ok, so it took a while, but I finally wrapped my head around some of this.
// define 'our' module
DefaultModuleDescriptor md
= new DefaultModuleDescriptor(ModuleRevisionId.parse("org#standalone;working"),
/* status = */ "integration",
new java.util.Date());
// add a configuration to our module definition
md.addConfiguration(new Configuration("compile"));
// define a dependency our module has on the (third party, typically) dependee module
DefaultDependencyDescriptor mainDep = new DefaultDependencyDescriptor(md, dependeeModuleId, /* force = */ true, false, true);
mainDep.addDependencyConfiguration("compile", "default");
mainDep.addDependencyConfiguration("compile", "sources");
// define which configurations we want to resolve (only have 1 in this case anyway)
ResolveOptions resolveOptions = new ResolveOptions();
String[] confs = new String[] {"compile"};
resolveOptions.setConfs(confs);
resolveOptions.setTransitive(true); // default anyway
resolveOptions.setDownload(true); // default anyway
ResolveReport report = ivy.resolve(md, resolveOptions);
This pulls down both the default jar as well as the sources target. Note that ivy has an issue where it won't transitively pull sources, though it will transitively pull 'main' jars. So you only get the sources for immediate dependency defined here, not the sub dependencies.
One other weakness I'm trying to figure out is this assumes the target dependency has a 'sources' configuration. I'd rather tell it to get any artifacts of type sources/source/src. Haven't figured that one out yet.
I am using the HybridSessionBuilder supplied by Palermo and his team .. link ..
We have our staging environments set up so that the url will be one of the following based on the environment
web-test.company.com
web-cert.company.com
web.company.com
what we normally do is take a look at the url and if it has "-test" we use the test configurations and so on (connection strings, etc).
This is the first project that uses nhibernate in this type of environment. What would be a good way to tell the Session Builder to use the correct hibernate cfg (I will build 1 for each environment).
The HybridSessionBuilder lives in an infrastructure layer and is injected into repositories via StructureMap.
Here's how I select a single configuration file using the HybridSessionBuilder:
public Configuration GetConfiguration()
{
var configuration = new Configuration();
string cfgFile = Path.GetDirectoryName(Assembly.GetAssembly(this.GetType()).CodeBase) +
"\\com.Data.nHibernate.cfg.xml";
configuration.Configure(cfgFile);
configuration.AddAssembly("com.Data");
return configuration;
}
If you want to select configuration files based on the URL I would just identify the call stack that leads to this function and pass in either an enum value or the config file's name directly.