I am a newbie.I am using Weblogic 10.0.0.0..I am getting an validation error in first page(Login Page wit user name and pwd) as "logger is not initialized",while deploying. I do the same thing with tomcat, and the .war is imported and deployed is success. What is the reason? and also ,in weblogic 10.0.0.0 we have two jdk's(jdk 1.6 and Jrockit)...in my system i m having 1.6.0_17..so which one it takes.i forgot which i choose while installing..whether it takes from wblogic jdk or which one?..wher i m going wrong..its a small one i notice..but could not figure out..plz lemme kno??
This is either because you haven't configured your WLS installation correctly. When you first setup your console there is a parameter you have to change in your auth file that if not set with cause this issue.
Or you are selecting logging during deployment from the admin console and you haven't configured log4j in your application.
Related
I have installed MobileFirst 6.3 appcenter console, worklight console successfully, they are operating fine on Tomcat/7.0.57. However when I try to install Operational Analytics, the documentation has the following
http://www-01.ibm.com/support/knowledgecenter/SSHS8R_6.3.0/com.ibm.worklight.installconfig.doc/monitor/c_op_analytics_installation_tomcat.html
I am using tomcat manager http://localhost:8080/html to deploy the war files. logging in as manager, with the manager-gui role.
worklight-analytics.war - deployed with no issues
when I select the worklight-analytics-service.war file and deploy in the GUI, it throws a blank page first, indicating "connection error", and when I refresh the page, on the status bar in Tomcat manager GUI, I get this message - "FAIL - Tried to use command /upload via a GET request but POST is required";
Please provide some direction on what I need to do get this fixed. I am not sure If I have provided all required information - please bear with me and ask, if anything relevant (obviously I can't figure out what is relevant yet) is required to debug.
So I was able to reproduce your error and I saw this in the logs:
java.lang.IllegalStateException:
org.apache.tomcat.util.http.fileupload.FileUploadBase$SizeLimitExceededException:
the request was rejected because its size (57353297) exceeds the
configured maximum (52428800)
It looks like by default, the web UI will only upload WARs of size 50MB or smaller. The analytics service WAR file is larger than this, so that is why this is failing. I was able to increase the limit by modifying the following lines in
/webapps/manager/WEB-INF/web.xml
<max-file-size>100000000</max-file-size>
<max-request-size>100000000</max-request-size>
This will increase the limit to 100MB. After I did this, I was able to successfully deploy the service WAR.
Just as a heads up, once you get the WAR deployed, you'll be presented with the login page. You'll need a tomcat user with the 'worklightadmin' role in order to get past the login screen.
The worklight-analytics-service WAR file does not have a user interface. It is simply referenced by the worklight-analytics WAR file. When both WARs have been deployed, can you see the analytics console? And does data load just fine? If so, then everything is fine. There is only an issue if you are unable to use the user interface provided by the worklight-analytics WAR file.
I'm using ActiveMQ 5.10 and would like to create a user that has read-only access through the web console.
Red Hat published this article, mentioning that it's not really read only due to a bug in ActiveMQ.
According to the bug report AMQ-4567, the bug is fixed as of ActiveMQ 5.9. However, I'm not seeing it work appropriately.
I have tried a number of different configurations, with the most recent being two separate JAAS implementations, one for Jetty and one for ActiveMQ. The relevant property files are excerpted below.
I can mostly log in to the web console using the "system" user. But the guest user doesn't work at all. The application user (appuser) doesn't need access to the web console at all.
My authN/authZ needs are pretty trivial: one admin user, one application account, and one read-only monitoring account.
Is there any good way to get this working with a recent version of ActiveMQ (>= 5.9.0)?
groups.properties
admins=system
users=appuser,admin
guests=guest
users.properties
system={password redacted}
appuser=appuser
guest=guest
jetty-realm.properties
system: MD5:46cf1b5451345f5176cd70713e0c9e07,user,admin
guest: guest,guest
As an aside, I used the Jetty tutorial and the Rundeck instructions to figure out the jetty-realm.properties file and chapter 6 of ActiveMQ in Action to work out the ActiveMQ JAAS.
I was finally able to get to what I wanted by deploying the web console to an external Tomcat instance. I assume that when it runs out of process, it can't bypass security and so has to use whatever credentials you provide. In this case, I gave the Tomcat instance the read-only JMX user credentials.
It's not great, as there is no security trimmed UI. You can still attempt to create new destinations, delete destinations, etc. When you try with a read-only user, you get an error. That gets a "D" for UX, but a "B" for security.
I've had an issue with glassfish for years and figured it was time to see if anyone else ran into this issue. All versions 3 and the latest 4.
I can deploy a web application (different instances on different servers/builds) with a default web module set with no issue. The web application starts up and runs fine.
The problem I'm having is that once I have to restart the server, simply relaunching the web server only shows a blank white screen with no error and no information anywhere. I have to then go into the admin console, undeploy the application, stop the glassfish server, redeploy, and then go back into the admin console and set the default web module.
If I do not set the default web module I do not run into these errors and I can stop/start/restart the server at will with no issues. It's only when I designate a default web module that it shows the blank screen. This is repeatable 100% for me.
Any ideas as to how to fix it? It takes far too long to get the application back up and running when this happens.
After a lot of research here is what I have found out.
The blank page means that the contextroot defined during deployment gets overwritten by the default contextroot which glassfish gets from the name of the WAR file being deployed.
If deploying an application with the name Application-1.0-SNAPSHOT.war from as admin console or admin GUI and you either specify the contextroot as:-
/application in the glassfish-web.xml configuration file or
from the admin console ./asadmin deploy --contextroot application path-to/Application-1.0-SNAPSHOT.war
The application with only be accessible from the browser by enter URL <domain-name>/Application-1.0-SNAPSHOT but what you want is your default web app to load when you access the domain name where it is deployed.
To achieve this you have to use the --name parameter to make sure that you the deployment name used matches the contextroot parameter value you want therefore
instead of:
from the admin console
./asadmin deploy --contextroot application path-to/Application-1.0-SNAPSHOT.war
you should do
./asadmin --name application deploy --contextroot application path-to/Application-1.0-SNAPSHOT.war
As a newbie to Enterprise Applications I'm trying to get it done.
I developed an Enterprise application in Netbeans 7.1.2. It runs successfully using the default Glassfish server. With the need to change the server, I downloaded and installed Tomee+ server, and made some changes to make Tomee Manager Interface work on my system.
I deployed the .ear file (Glassfish server output) into Tomee+ by placing it in the Tomee webapps folder, with the server in the running state. It gets automatically deployed and appears in the Tomcat Web Application Manager interface.
Then, by providing the suitable path in the address bar, like http://localhost:8080/app-war/faces/app.xhtml, it provides the frontend screen but the backend process is not working if I click the submit button. Instead, it simply provides a status page, like HTTP Status 500 - javax.el.ELException: javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, presumably because setRollbackOnly was called during a synchronization.
My question is: what went wrong with the steps I took for deploying it in Tomee+ server?
no more verbose stack?
btw can you try to:
1) check you have in tomee.xml the line
2) put your ear in /apps/ instead of webapps/
The point is by default (can be configured with the snapshot/next release) tomee extracts the ear in a folder simply removing the extension (webapps/your-ear/ for instance) and then tomcat takes this folder as a webapp so your deployment is no more the one expected. That's why moving it over a folder not managed by tomcat (apps) is often enough.
That's said, Glassfish transaction management is sometimes too tolerant (why i ask the full stack you got).
i have EAR file contains jar and war packages.this ear file deploy on glassfish correctly but when deploy this ear file on weblogic 12c, get this error :
Unable to access the selected application.
Error Exception in AppMerge flows' progression
Error Exception in AppMerge flows' progression
Error Unable to resolve deadlock in factory claims
Error Unable to resolve deadlock in factory claims
i check application.xml and name of jar and war packages are correct.anybody have idea for solving this issue ?
I too had this problem and tried everything (schemas, project structure, dependant libs, etc). Finally compared my domain with the sample "medrec", the only difference was that I had added SIP support. After removing this support, I can now deploy my EAR with included WAR and EJBs. I assume this is a bug in 12c...
I too had the same problem and I had to create another domain to resolve the issue.The key here is not to use the eclipse tool to create the the domain as the option to create "Basic Weblogic Domain" is not presented.
The option to create a basic weblogic domain is presented when you launch the weblogic domain creation wizard.
I had faced the exact same problem today. This problem is associated with the way the Domain was created. If you have used "Basic WebLogic SIP Server Domain" then it would occur while installing an ear. You can double check if the Domain is created with Basic SIP or not, go to your Weblogic Server Domain >> bin >> setDomainEnv (cmd or sh) file and check if you have the below properties defined.
-- set WLSS_HOME=C:\Oracle\Middleware\wlserver_12.1\sip
-- set SIP_ENABLED=true
I tried to create the Domain again with JAX-RPC extension instead of Basic SIP and got this problem resolved.