I'm developing a custom application for IBM BPM that uses these libraries: Jace.jar, pe.jar, log4j.jar, stax-api.jar, xlxpScanner.jar and xlxpScannerUtils.jar that are used to call a web service.
When I create a java project and add those libraries, it works fine. It also works ok when I create a dynamic web project using tomcat 8 as server; but when using jboss I don't get the expected result when calling the web service. So, does anybody know how to disable the modules that use these libraries? Or where to find information about it?
I want my application to be server independent.
This is my code:
try {
VWSession vwSession = new VWSession("userName", "userPass", "connPt");
vwSession.isLoggedOn(); /* It's loaded with 'false' value in jboss.
In tomcat it's loaded with 'true' value */
} catch (Exception e) {
Logger.getLogger(getClass().getName()).log(Level.FATAL, "Details: ", e);
}
To create an application that is server agnostic, you need to strictly adhere to Java EE specification. Meaning, use only those jars that are bundled as part of the Java EE version you are using. Then too, there are certain deployment descriptors specific to a given application server that would need to be used in some cases. For example - jboss-deployment-structure.xml, ibm-application-bnd.xml, etc.
In your case, xlxpScanner.jar is not a part of the Java EE spec, so making the application server independent is not possible with the current settings. You could look for a replacement of the part of this jar you are using with something Java EE has. In short, get rid of this jar alongwith xlxpScannerUtils.jar.
Alternatively, if you want jboss to run the application properly, add all the jars in a module and give it to the EAR/WAR using jboss-deployment-structure.xml. Details can be found here.
Related
Why we need ibm-web-bnd.xml and ibm-web-ext.xml in application that we need to run in WAS server. I found few things like it contain virtual host , context root etc. But i want to know why it is required for WAS server.
First of all they are not required, they can be generated during the installation for example via web admin console. However they can provide some predefined settings or change the default behavior.
The ibm-web-bnd.xml file provided binding between resource references used in web module and actual components, like datasouces, queues, etc. However since Java EE 6, you can actually use the lookup attribute from the #Resource annotation to provide them in the code. See some more info about bindings here - Application bindings
The ibm-web-ext.xml file allows you to configure some settings for web module e.g. context-root, directory browsing, etc and JSP engine parameters.
The easiest way to create them is to use WebSphere Developer Tools for Eclipse (free plugin), which have graphical/text editor for them.
I'm writing web applications with Java EE 7 using JSP and servlets, deploying to a local Wildfly 10 server.
To help me developing and testing my code, it would be useful to include a little timestamp into the displayed webpage, so that I can directly see when the version I'm looking at in my browser was deployed.
That would prevent me from both forgetting to deploy changes as well as from looking at old cached versions instead of the latest one.
How can I display the date and time when a Java EE web app got deployed to my Wildfly server directly on the webpage?
My IDE is Eclipse Neon for Java EE, if that matters.
This is not deploytime, but starttime of the application. Maybe it is useful for your purpose. You can inject the class and use it to display data on your page.
#Startup
#Singleton
public class Deploytime
{
private LocalDateTime starttime;
#PostConstruct
public void init() {
starttime = LocalDateTime.now();
}
}
Apart from that I can only think of Maven Git Plugin which can generate things like buildtime, commit id, ... into a propery file, which you can also use to display it on the page (if you use git/maven).
There is likely an API to do this too but you can get the server start time from the command line. Assuming that you have your admin user name and password set up (i.e. you've run something like add-user.sh) you could run:
curl --digest "http://user:password#localhost:9990/management/core-service/platform-mbean/type/runtime?operation=attribute&name=start-time"
Of course, this is not Java - you'd either have to do a System.exec on this or use something like HttpClient. Additionally, the big issue here is that you've got to have your admin username and password available to the code.
The Wildfly HTTP Management Docs go into some more detail with a small sample Java snippet.
EDIT:
Sorry - should not have assumed that the server restarts on deployment. You can get deployment time for a web app with:
curl --digest "http://user:password#localhost:9990/management/deployment/test-1.0-SNAPSHOT.war/?operation=attribute&name=enabled-time"
However, that seems more difficult than the other answer of running something at startup. I don't see a deployment time for a webapp as that time would have to be stored somewhere in case of server restarts.
I want to convert spring application into angular js. I am using some external css and js.
css is included properly but not js.
when I use
<script src="bower_components/angular/angular.min.js"></script>
It is considering angular.min.jsp and throwing error not found.
How to include external js into my app.
It seems as some misconfiguration on the server side.
I would suppose that you are using Apache 2.4 or Tomcat 7
In Apache 2.4 take a look at https://httpd.apache.org/docs/2.4/rewrite/remapping.html
If you were running the application in the ubuntu then default location to look at would be /etc/apache2 and usually this is going to be found in /etc/apache2/sites/available/000-default.conf
In Tomcat 7 take a look at
https://tomcat.apache.org/tomcat-8.0-doc/rewrite.html
Under Ubuntu with the default installation of Tomcat, this information will be found either in the file /var/lib/tomcat7/conf/server.xml or under the directory your application is deployed in META-INF/context.xml or under /var/lib/tomcat7/Catalina in one of the subdirectory. This depends a lot on the settings you have.
If neither of these is a case then take a look at the filters applied to the application as some of them can screw the answer. For them take a look at WEB-INF/web.xml or if you are using the XML-less configuration then try Some of the I believe SpringWebApplication classes.
If you still use the Spring to serve the backend then it is also possible that you have incorrectly set up ViewResolver, which returns .jsp as appendix instead of .js
We need to send mail from a log handler in GlassFish v3.1.2.2.
We've tried to use smtphandler-0.6 and -0.7 with limited success. We install the jarfile to domain/lib/ext, and configure smtphandler's properties in domain/config/logging.properties. We've tried two ways of satisfying smtphandler's reliance on mail imports: 1) Editing its manifest classpath to point to ../../../../modules/javax.mail.jar, and 2) Putting javax.mail.jar in domain/lib/ext alongside the smtphandler jar. (We prefer the former approach so that the same javamail classes are used throughout the system. But it seems to make no difference, no worky either way.)
With either of these arrangements the behavior is the same:
The handler loads ok as shown by the JVM's verbose:class output.
Sometimes it sends mail for errors and warnings that occur during domain startup (like the expired certificate). Other times it fails as described below before ever sending mail.
It always fails once we've deployed our application and logged some application errors. We can tell that the handler is invoked - that's evidenced by the debugger and some primitive System.out "logging".
The root problem is a NoSuchMethodException: com.sun.mail.smtp.SMTPTransport.[init](Session, URLName). The failure to find the c'tor means the transport object can't be created; that eventually manifests as a NoSuchProtocolException.
We can see that the SMTPTransport class is loaded and that it has the requested c'tor. Our best theory is that class loading is somehow involved, but we've not been able to figure out exactly how. (Yet. We're working that angle now.)
Questions:
Are we deploying the handler to the correct location (domain/lib/ext) ?
Why does it (sometimes) send mail during an (empty, no apps) domain startup, but fail for logs emitted by our application? That's a race condition, surely, but what are those threads doing that occasionally works for a bit then reliably fails?
Are we right to think that all these indications together imply a class loading issue?
We've reproduced these symptoms on GlassFish versions 3.1.2.2 and 4, with JavaMail 1.4.4 and 1.5.
Thanks in advance for any help.
Looks like a bug was reported for this NoSuchMethodException when attempting to install log handler in GlassFish server. This issue was raised with the JavaMail team under Bug K6668 | GH144 - skip unusable Store and Transport classes which is fixed in JavaMail 1.5.3. Upgrading the JavaMail module in glassfish and all other copies deployed should correct the issue. It is also helpful to start glassfish with "glassfish/bin/asadmin start-domain -v" so you can see all bootstrapping messages.
•Are we deploying the handler to the correct location (domain/lib/ext)
Yes. You can deploy to domain/lib/ext but you have to include JavaMail 1.5.3 so you find the correct transport service. Otherwise, you can deploy the jar to the modules dir and add the HK2 metadata to make the smtphandler look like a service. This can be done by including new jar or modifying the existing smtphandler jar.
For GlassFish 3, the file META-INF/inhabitants/default must be added containing the following:
class=smtphandler.SMTPHandler,index=java.util.logging.Handler
For GlassFish 4, the file META-INF/hk2-locator/default must be added containing the following:
[smtphandler.SMTPHandler]
contract={java.util.logging.Handler}
scope=javax.inject.Singleton
The jar then has to be placed in the glassfish/modules folder along with upgrading javax.mail.jar.
Another option is to subclass smtphandler to look like a HK2 log handler service and add a preDestroy method to trigger the email on shutdown. This is described in the Oracle GlassFish Server 3.1 Administration Guide Part I section 7 titled Adding a Custom Logging Handler.
Under GlassFish 4 there are two different ways to locate a handler in the logging.properties. Handlers placed in domain/lib/ext use the standard handlers key in the properties file. Handlers placed in the glassfish/modules as a HK2 Service are loaded using the handlerServices key in the properties file.
#GF3 ext/endorsed or OSGI. GF4 ext/endorsed only.
handlers=smtphandler.SMTPHandler
#GF4 OSGI only, 'handlerServices' should not contain any whitespace characters between handlers.
handlerServices=com.sun.enterprise.server.logging.GFFileHandler,smtphandler.SMTPHandler
•Why does it (sometimes) send mail during an (empty, no apps) domain startup, but fail for logs emitted by our application? That's a race condition, surely, but what are those threads doing that occasionally works for a bit then reliably fails?
Difference in context class loader between messages logged by GF vs your web app. The CCL is used in JavaMail to locate the transport. Patching the 'sendBuffer' method should fix the behavior:
#Override
protected void sendBuffer() {
final Thread thread = Thread.currentThread();
ClassLoader ccl = null;
try {
ccl = thread.getContextClassLoader();
thread.setContextClassLoader(
javax.mail.Transport.class.getClassLoader());
} catch (SecurityException ignore) {
}
try {
super.sendBuffer();
} finally {
try {
thread.getContextClassLoader();
thread.setContextClassLoader(ccl);
} catch (SecurityException ignore) {
}
}
}
•Are we right to think that all these indications together imply a class loading issue?
Yes. The only way to really make this work right is to subclass or patch the smtphandler to look like an HK2 component and modify the CCL.
We need to send mail from a log handler in GlassFish v3.1.2.2.
We've tried to use smtphandler-0.6 and -0.7 with limited success.
Disclaimer: I'm a content developer for MailHandler included with JavaMail project.
An alternative to the smtphandler is the com.sun.mail.util.logging.MailHandler included with the JavaMail reference implementation.
Under GlassFish 4 you have to have glassfish/modules/javax.mail.jar that is JavaMail 1.5.3 or newer. An updated version can be downloaded from the JavaMail API homepage and can be used to replace the version bundled with GlassFish.
Next you have to modify the logging.properties for the domain. Here is a sample configuration you can include to get you started.
#Ensure no whitespace between handler class names.
handlerServices=com.sun.enterprise.server.logging.GFFileHandler,com.sun.mail.util.logging.MailHandler
com.sun.mail.util.logging.MailHandler.subject=com.sun.mail.util.logging.CollectorFormatter
#com.sun.mail.util.logging.CollectorFormatter.format=GlassFish 4.x:{0}{1}{2}{4,choice,-1#|0#|0<... {4,number,integer} more}
#com.sun.mail.util.logging.CompactFormatter.format=[%4$-7.7s] %7$#.140s
com.sun.mail.util.logging.MailHandler.level=WARNING
com.sun.mail.util.logging.MailHandler.filter=com.sun.mail.util.logging.DurationFilter
com.sun.mail.util.logging.MailHandler.pushLevel=WARNING
com.sun.mail.util.logging.MailHandler.mail.smtp.host=some-smtp-host
#com.sun.mail.util.logging.MailHandler.mail.user=some-user
#com.sun.mail.util.logging.MailHandler.authenticator=some-password
com.sun.mail.util.logging.MailHandler.mail.from=app#server.com
#com.sun.mail.util.logging.MailHandler.mail.sender=team#list.com
com.sun.mail.util.logging.MailHandler.mail.to=devs#bugfixers.com
com.sun.mail.util.logging.MailHandler.verify=resolve
com.sun.mail.util.logging.MailHandler.mail.smtp.quitwait=false
com.sun.mail.util.logging.MailHandler.mail.smtps.quitwait=false
com.sun.mail.util.logging.MailHandler.mail.smtp.connectiontimeout=45000
com.sun.mail.util.logging.MailHandler.mail.smtps.connectiontimeout=45000
com.sun.mail.util.logging.MailHandler.mail.smtp.timeout=45000
com.sun.mail.util.logging.MailHandler.mail.smtps.timeout=45000
For GlassFish 3 you have to install JavaMail (javax.mail.jar) under the domain/lib/ext or glassfish/lib/endorsed and test that this doesn't break any of your applications. This classloader configuration also works under GlassFish 4 and allows combining the MailHandler with MemoryHandler which can emulate the behavior of the smtphandler.
Next you have to modify the logging.properties for the domain. You can use the same sample as the GlassFish 4 except that you have to use the standard handlers tag instead of the handlerServices.
handlers=java.util.logging.MemoryHandler
java.util.logging.MemoryHandler.target=com.sun.mail.util.logging.MailHandler
java.util.logging.MemoryHandler.size=512
java.util.logging.MemoryHandler.level=INFO
java.util.logging.MemoryHandler.push=WARNING
com.sun.mail.util.logging.MailHandler.capacity=512
com.sun.mail.util.logging.MailHandler.level=INFO
com.sun.mail.util.logging.MailHandler.pushLevel=WARNING
com.sun.mail.util.logging.MailHandler.filter=com.sun.mail.util.logging.DurationFilter
com.sun.mail.util.logging.DurationFilter.records=512
com.sun.mail.util.logging.DurationFilter.duration=5*60*1000
I am working in a Java EE project that integrates with SAP system, and I am trying to run a simple standalone java class that calls a RFC. My snippet of code is
JCO.Client mConnection =
JCO.createClient("dummy", // SAP client
"dummy", // userid
"dummy", // password
"dummy", // language (null for the default language)
"dummy", // application server host name
"dummy"); // system number
It throws the following exception "JCO.classInitialize(): Could not load middleware layer 'com.sap.mw.jco.rfc.MiddlewareRFC'
JCO.nativeInit(): Could not initialize dynamic link library sapjcorfc"
The only library that i have in this moment is sapjco.jar, i have seen in some foruns that i need this two libraries (librfc32.dll , sapjcorfc.dll) to be able to run this code in an standalone application. Is that right ? Where can i get this two libraries ? The last one is to put in the same folder than the sapjco.jar, is that ok to ?
If I can not run this in my local computer I will have to deploy the application every time that I want to test it :(
Depending on which JCo version you use (you didn't state that), you need one or two platform-specific native libraries. They come bundled with the JCo package, along with some installation documentation. If you don't have this, you've got an incomplete and probably illegal package (redistribution is not allowed). Go to http://service.sap.com/connectors and get the valid one.