Tomcat generates empty access log file - java

Since I need the runtime information of every request processed by Tomcat, I've configured the access log output for Tomcat in the file {$CATALINA_HOME}/conf/server.xml as following. But when running the application, the access log file just stays empty. Anybody knows the reasons? Thanks a lot!
<Host name="localhost" appBase="deploy"
unpackWARs="true" autoDeploy="true">
<!-- SingleSignOn valve, share authentication between web applications
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->
<!-- Access log processes all example.
Documentation at: /docs/config/valve.html
Note: The pattern used is equivalent to using pattern="common" -->
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="/home/admin/shopcenter/logs/"
prefix="localhost_access_log"
suffix=".log"
buffered="false"
encoding="GB18030"
pattern="common"/>
</Host>

Related

Deploying Java application to Tomcat root directory in Digitalocean [duplicate]

This question already has answers here:
Deploying my application at the root in Tomcat
(10 answers)
Closed 8 years ago.
I tried to deploy my application file to Tomcat 7. I have successfully deployed them, but I can see my files only under http://example.com:8080/myproject/index. (Assume that my project folder is myproject and my domain is example.com.)
I would like to to access to my domain like this: http://example.com/index.
How can I do that?
ok
I have solved the problem.
in the default server.xml file tag like this,
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<!-- SingleSignOn valve, share authentication between web applications
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->
<!-- Access log processes all example.
Documentation at: /docs/config/valve.html
Note: The pattern used is equivalent to using pattern="common" -->
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log." suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
</Host>
but I have removed that and changed like these
<Host appBase="webapps" name="example.com" unPackWars="true" autoDeploy="true">
<Context path="" docBase="myproject" debug="0" reloadable="true"/>
</Host>
<Host appBase="webapps" name="www.example.com" unPackWars="true" autoDeploy="true">
<Context path="" docBase="myproject" debug="0" reloadable="true"/>
</Host>
and than I have changed
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
like this
<Connector port="80" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
now it works:)

Tomcat 8 - static resources / assets can't get this working

C:\asset (there I have images like 1.jpg / 2.jpg / 3.jpg etc)
My tomcat server.xml looks like this:
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<Context path="/test" docBase="C:/asset" debug="0" reloadable="true" crossContext="false"/>
<!-- SingleSignOn valve, share authentication between web applications
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->
<!-- Access log processes all example.
Documentation at: /docs/config/valve.html
Note: The pattern used is equivalent to using pattern="common" -->
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log" suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
</Host>
Still when i go to localhost:8080/test/1.jpg I have 404 error any ideas why this don't work ?
Another question is there any possibility to configure this path in my spring project ? As a variable ?

Session attributes not getting replicated properly in tomcat 7 clustering

I have the following code in struts2.3 ::
SessionEvent se = new SessionEvent();
se.setSessionID(session.getId());
se.setUserID(user.getUserId());
session.setAttribute("SessionEvent", se);**
Map attributes = ActionContext.getContext().getSession();
attributes.put("USER", user); // user is a serialized object
attributes.put("ID", 0);
ActionContext.getContext.setSession(attributes);
CustomSessionManager cst = new CustomSessionManager();
cst.setUserID(user.getUserId());
cst.setUserMachineIP(req.getRemoteHost());
cst.setUsersessionId(session.getId());
session.setAttribute("boundUnboundUser", cst);
SessionEvent And CustomSessionManager are Serialized Listener classes ::
public class SessionEvent implements HttpSessionBindingListener, Serializable
{
public void valueBound(HttpSessionBindingEvent arg0)
{
}
public void valueUnbound(HttpSessionBindingEvent arg1)
{
}
}
public class CustomSessionManager implements HttpSessionBindingListener, Serializable
{
public void valueBound(HttpSessionBindingEvent arg0)
{
}
public void valueUnbound(HttpSessionBindingEvent arg1)
{
}
}
Now the problem is that at replication time DeltaManager is able to replicate the SessionEvent and CustomSessionManager Object but unable to replcate user object . Now if i change the sequence of code and put the session code for user above Session Event then user object gets replicated but Custom Session Manager does not . Not sure whether this is a problem in my code or there is problem in behavior of Delta Manager in tomcat 7 . I have marked my web application as also . My Receiver ports of tomcat are also different . I am using sticky session . Following is server.xml configuration for cluster
I have also specified jvmRoute attribute inside Engine tag in server.xml file . I am using mod_proxy_balancer for load balancing
<!--For clustering, please take a look at documentation at:
/docs/cluster-howto.html (simple how to)
/docs/config/cluster.html (reference documentation) -->
<!--
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
-->
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="8">
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.4"
port="45569"
frequency="500"
dropTime="3000"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
</Sender>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4001"
autoBind="100"
selectorTimeout="5000"
maxThreads="6"/>
<Interceptor
className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor
className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
<!-- Use the LockOutRealm to prevent attempts to guess user passwords
via a brute-force attack -->
<Realm className="org.apache.catalina.realm.LockOutRealm">
<!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true" deployXML="true">
<!-- SingleSignOn valve, share authentication between web applications
Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
-->
<!-- Access log processes all example.
Documentation at: /docs/config/valve.html
Note: The pattern used is equivalent to using pattern="common" -->
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log." suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
</Host>
</Engine>

How to map domain to web application deployed on Tomcat 7 in Ubuntu?

I have a Java based web application which is deployed on Ubuntu machine. I can access the web application at localhost:8080 and it is working as expected.
Now I have domain name for the web application and I want to access web application through the browser using the domain name(http://www.xyz.com).
I want to know the steps which are required to achieve it. Before posting this question, I search over the google.
I have already added the host details in the conf/server.xml.
<Host name="xyz.com" appBase="webapps" unpackWARs="true" autoDeploy="true">
<Alias>www.xyz.com</Alias>
<Context path="" docBase="" debug="0" privileged="true" />
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs" prefix="localhost_access_log." suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" resolveHosts="false" />
</Host>
Also, I made changes in the /etc/hostname and added following
<IP Address> www.xyz.com xyz
What else do I need to do?

Tomcat 7 nesting CombinedRealm, LockoutRealm and DataSourceRealm

I'm trying to nest Realms as follows in Tomcat 7.0.32 (written here in pseudo-XML):
<CombinedRealm>
<LockoutRealm>
<DataSourceRealm/>
</LockoutRealm>
<UserDatabaseRealm/>
</CombinedRealm>
This doesn't seem to work - is it possible to nest Realms in Tomcat by more than two levels? I get a warning in the logs:
No rules found matching 'Server/Service/Engine/Realm/Realm/Realm'.
The idea behind is that the web service has some critical users that must not be locked out (e.g. as a DOS) and some normal users, which may have weaker passwords, where the lockoutRealm should be active. I'm sure other people have been in this situation.
If there is another way to achieve this (e.g. a whitelist for the LockoutRealm), please let me know.
Single sign on is also needed.
I guess extending the existing LockoutRealm code with a list of accounts never to lock out would be an option, but I'm not so keen on writing my own Realm, I would rather not add custom code on that level to Tomcat, as this will complicate setup for others and with every Tomcat update it might break etc.
Thanks for any help!
Here is the relevant part of server.xml of my test config:
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.CombinedRealm">
<!-- Lockout realm for the DB users -->
<Realm className="org.apache.catalina.realm.LockOutRealm">
<!-- PRIMARY: DataSourceRealm with user DB -->
<Realm className="org.apache.catalina.realm.DataSourceRealm"
dataSourceName="jdbc/authority"
userTable="user" userNameCol="username"
userCredCol="password" digest="SHA"
userRoleTable="user_role" roleNameCol="rolename" />
</Realm>
<!-- FALLBACK:
This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
<!-- SingleSignOn valve, share authentication between web applications
Documentation at: /docs/config/valve.html -->
<Valve className="org.apache.catalina.authenticator.SingleSignOn" />
<!-- Access log processes all example.
Documentation at: /docs/config/valve.html
Note: The pattern used is equivalent to using pattern="common" -->
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log." suffix=".txt"
pattern="%h %l %u %t "%r" %s %b" />
</Host>
</Engine>
Apache commons-digester is used to parse the configuration files, so I suspect this particular use case simply wasn't expected.
Tomcat's org.apache.catalina.startup.RealmRuleSet.addRuleInstances seems rigged to only go 2-levels deep for Realm configuration. Seems simple enough to add another layer in there.
I'd have to look at how the digester can be configured to see if arbitrary levels could be supported, or if some subset would have to be manually configured.
Feel free to head over to the Tomcat users' list to request such a change.
The new answer is now:
Update to Tomcat 7.0.33 or later. Then it works perfectly.
Christopher Schultz was so friendly to forward my question here to the Tomcat user list. The great Tomcat developers have immediately addressed the issue and put this in the next release. Thanks a lot!
So you can now use a construction like the one in the question or like this with different order / "priorities":
...
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.CombinedRealm">
<!-- PRIMARY: tomcat-users.xml with critical system users
that should always work, DB independent and without lockout
NOTE: If the wrong password is given, the secondary path with
lockout is still attempted, so that a lockout on that path
will still occur and be logged. Still the primary path is not
locked for access by that happening. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase"/>
<!-- SECONDARY: DataSourceRealm with DB with lockout functionality -->
<!-- (three level nesting of realms requires Tomcat >= 7.0.33) -->
<Realm className="org.apache.catalina.realm.LockOutRealm"
failureCount="5" lockOutTime="60" > <!-- note that when an account is locked correct password
login is no longer possible (would otherwise defeat purpose of lockout),
but also lockoutTime is still reset in each correct attempt -->
<Realm className="org.apache.catalina.realm.DataSourceRealm"
dataSourceName="jdbc/authority"
userTable="user" userNameCol="username"
userCredCol="password" digest="SHA"
userRoleTable="user_role" roleNameCol="rolename" />
</Realm>
</Realm>
<Host >
...
</Host>
</Engine>
...
Of course you may also use other Realms and other combinations.
Note that one thing can be misleading in the logs: In this construction, if a wrong password is given for one of the critical users stored in the primary realm, the primary realm denies access, then the secondary realm via the lockout realm is tried and also denies access eventually locking out the username. This is logged by the lockout realm as a warning "An attempt was made to authenticate the locked user ...". Still with correct password, access keeps working via the primary realm, as it does not go via the lockout realm. I.e. all works as intended, just the log message could lead to confusion (of course this is impossible to avoid).

Categories