GWT: how to write client side logs into a log file in GWT - gwt

HI guys i am facing a big problem to write logs in a file in GWT.
i ahd gone through all the posts over internet but i didn't find any valuable information
there.
What i did ...
added remote logging servlet in web.xml file
inherited the logging module in my .gwt.xml file.
But my question is here now suppose i have written one log in my Entry Point class.
like ....
//Main class to start the appliation.....
public void onModuleLoad() {
Logger logger=Logger.getLogger(SYTMain.class.getName());
logger.info("Test Log in Module File");
}
and now i want to write this client side log into a test.log file .
How i can achieve this???/
Please if anyone knows the answer then plz provide me the complete solution, i don't want example on a fly. if you really know then only plz tell me don't give the answer which is already available in net.....
mY delivery date is very near so plz update on same ASAP, i'll be very thankful to you.

In your module file add the following:
<inherits name='com.google.gwt.logging.Logging'/>
<set-property name="gwt.logging.enabled" value="TRUE"/>
<!-- Set logging level to INFO -->
<set-property name="gwt.logging.logLevel" value="INFO"/>
<set-property name="gwt.logging.simpleRemoteHandler" value="ENABLED" />
<!-- Add compiler.stackMode to get a readable stacktrace from JavaScript
It generates a set of files in WEB-INF/deploy; those files need to
be placed on the server
-->
<set-property name="compiler.stackMode" value="emulated" />
In your web.xml add the following:
<servlet>
<servlet-name>remoteLoggingService</servlet-name>
<servlet-class>com.google.gwt.logging.server.RemoteLoggingServiceImpl</servlet-class>
</servlet>
<!-- Servlet Mapping -->
<servlet-mapping>
<servlet-name>remoteLoggingService</servlet-name>
<url-pattern>/<your module name>/remote_logging</url-pattern>
</servlet-mapping>
Replace <your module name> with as it says your module name.
To log simply use the code as your mentions. Use the import from java.util.logging.

On the client side, GWT compiles to Javascript, and Javascript cannot in general write files to the client's filesystem. (It should be obvious why this could be a bad idea). See for example this discussion.
If what you need is logs to use for debugging, one obvious solution is to have the logger append to a text area on the page. You can always copy and past manually into another file. Or, if you want to debug remotely, you could have the logger write to the server.

Just create a RPC service to log it into the server-side.
Use the servlet-side threadlocal to get info about the client: ThreadLocal to store ServletRequest and Response in servlet: what for?.

Related

How to add the description of job in spring batch admin user interface?

Is there any way to add the description of job at the user interface of spring batch admin?
Although, I tried to added the description of the job, spring batch admin cannot support it.
I would like to know that whether spring batch admin does not support it or not.
I know i'm late to the party but I figured it out and it works flawlessly for me. All you have to do is :
Add a messages.properties file in your classpath (under
src/main/resources).
Add yourJobName.description=Your description goes here in that file.
Override manager-context.xml for SBA by creating a file on path src/main/resources/META-INF/spring/batch/servlet/override/manager-context.xml
The content of the above created file should be :
`
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
<!-- Override messageSource bean in order to provide custom text content -->
<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
<property name="basename" value="messages" />
</bean>
</beans>
`
That's it. Your custom description shows up in SBA. Hope this helps someone who's looking for it.
There isn't the ability out of the box to display the job's description. That is only contained in the XML and the data seen in the UI comes from the JobRepository. You'd have to extend the UI to add that functionality.

GWT: Servlet URL mapping gives a 404 error

I have read the other GWT Servlet questions, but I'm having trouble solving my problem still. My package is called Maps, and it has a service named MyService (which was set up according to a GWT Tutorial). The web.xml file includes the following:
<servlet>
<servlet-name>MyServiceImpl</servlet-name>
<servlet-class>com.xerox.maps.maps.server.MyServiceImpl</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MyServiceImpl</servlet-name>
<url-pattern>/Maps/service</url-pattern>
</servlet-mapping>
In MyService, I have the line:
#RemoteServiceRelativePath("service")
public interface MyService extends RemoteService { ...
However, when I try to make an RPC call, there is an error thrown. The details of the error say that it is a 404 HTTP error. How can I fix this, to make sure that the mapping is correct?
Edit 7.27
MyService.java contains the annotation:
#RemoteServiceRelativePath("service")
And web.xml contains:
<servlet-name>MyServiceImpl</servlet-name>
<url-pattern>/com.x.maps.Maps/service</url-pattern>
If I follow the XHR with FireBug, it shows me that there is a call to com.x.maps.Maps
404 Not found is thrown usually when service endpoint path is inferred wrongly by GWT. Try removing #RemoteServiceRelativePath("service") and recompile and check, If that does not work find out the URL endpoint of the service manually (by hitting likely paths from a browser till the error changes to 500 internal error) and then give the correct path as argument to #RemoteServiceRelativePath("correct/path"). Few trials I would try right away is #RemoteServiceRelativePath("/Maps/service") and #RemoteServiceRelativePath("Maps/service") without the slash
According to this tutorial:
https://developers.google.com/web-toolkit/doc/latest/tutorial/RPC
The servlet-mapping should be composed of the module "rename-to" and the service "RemoteServiceRelativePath". So, if you have, in your *.gwt.xml file, the following line:
<module rename-to='XXX'>
And in your *Service.java file you have the following line:
#RemoteServiceRelativePath("YYY")
Then, in your "web.xml" file, you should have the following lines:
<servlet-mapping>
<servlet-name>...servlet-name>
<url-pattern>/XXX/YYY</url-pattern>
</servlet-mapping>
New answer after all the comments :
Cool, you have made progress!
You are hitting this URL -
http://127.0.0.1:8888/com.x.maps.maps.Maps
With this POST data I assume - /%7C98544A4AED8C7D42E80C55859E9CEC4C%7Ccom.x.maps.maps.client.MyService%7CreadFile%7Cjava.lang.String/2004016611%7CPrinterList.xls%7C1%7C2%7C3%7C4%7C1%7C5%7C6%7C
This is where the problem is, your servlet is mapped to respond to XHR requests coming to <url-pattern>/Maps/service</url-pattern> but you are hitting /com.x.maps.maps.Maps instead. Hence you are getting the 404 path not found status code.
Alter the url-pattern on the server-side web.xml to match what the browser is making,
OR
Alter the GWT code using the RemoteServiceRelativePath annotation to make the request to /Maps/service instead of to /com.x.maps.maps.Maps
I have had the same problem but I solved it changing the url-pattern of the Servlet in the web.xml
Try to put in your web.xml the path to the directory where your GWT javascript module is generated, behind WEB-INF/deploy. in my case:
<url-pattern>/gwtmodulemain/selection</url-pattern>
You can also rename your module name in your gwt.xml file:
<module rename-to='gwtmodulemain'>
so you can refer your module from your HTML in this way:
<script type="text/javascript" language="javascript" src="gwtmodulemain/gwtmodulemain.nocache.js"></script>
Good luck!

Configure logging with Lift

The Lift wiki page on logging states that a lot of setup is done automatically. Right now my problem is that I already have a running backend with its own logging configuration and a log4j.properties file in my classpath which should be used. There are also dependencies to log4j and SLF4j already in the classpath.
The main problem is that I get complete debug output for everything. Hibernate in particular -- which is very annoying.
I am using Lift 2.3-M1 and tried doing the following in the beginning of boot():
Logger.setup = Full(Log4j.withFile(getClass().getResource("/props/log4j.xml")))
The log4j.xml I am currently using is quickly hacked together to simply suppress DEBUG output.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/xml/doc-files/log4j.dtd">
<log4j:configuration threshold="info" xmlns:log4j="http://jakarta.apache.org/log4j/">
<appender name="CA" class="org.apache.log4j.ConsoleAppender">
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="[%p] %c{2} %m%n"/>
</layout>
</appender>
<root>
<level value="info"/>
<appender-ref ref="CA"/>
</root>
</log4j:configuration>
When I create an errornous log4j.xml I also get an error from the SAXParser so it must be parsed. However I am still getting all DEBUG output. A second try was doing the following:
LiftRules.configureLogging = () => ()
Logger.setup = Full(Logback.withFile(getClass().getResource("/props/log4j.xml")))
Since I do not want to have Lift configure logging for me since the backend is already configured I would like to turn it completely off now. Oh and I also tried LogBoot.logSetup = () => false with no luck.
I would greatly appreciate any help on this issue.
The question got answered on the Lift mailing list.
The fix is to remove the logback dependency and to include both log4j and slf4j-log4j. No other configuration in boot() is required besides a valid default.log4j.xml.
I had a similar problem and came upon the following solution:
import net.liftweb.common.{ Empty, Logger }
import net.liftweb.http.Bootable
class BootLoader extends Bootable {
def boot = {
// other boot configuration ...
// prevent Lift from messing up my log4j config
Logger.setup = Empty
}
}

WCF Web Service Metadata Publishing Disabled Error

I modified my web.config to add a custom binding in order to increase the buffer and message size, and it seems like in creating the service element explicitly, it has somehow broken the reference to my behavior element.
When I try to run my web service from VS using the WCF Test Client, or I go to the service page, I get the error:
Metadata publishing for this service is currently disabled.
I've compared my web.config to a few different sources on this and everything seems to match. I've no idea what the issue is.
Here is the System.serviceModel element:
<system.serviceModel>
<services>
<service name="BIMIntegrationWS.BIMIntegrationService" behaviorConfiguration="metadataBehavior">
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
<endpoint address="http://localhost:1895/BIMIntegrationService.svc"
binding="customBinding" bindingConfiguration="customBinding0"
contract="BIMIntegrationWS.IBIMIntegrationService"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="metadataBehavior">
<!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpGetEnabled="true"/>
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<customBinding>
<binding name="customBinding0">
<binaryMessageEncoding />
<httpTransport maxReceivedMessageSize="262064"
maxBufferSize="262064"
maxBufferPoolSize="262064" />
</binding>
</customBinding>
</bindings>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" aspNetCompatibilityEnabled="true"/>
It almost seems like either the web service page is not finding the element. I don't get an error complaining that the target behaviorConfiguration doesn't exist, or anything like that, just that Metadata publishing is not enabled.
Any help would be greatly appreciated.
Thanks.
I think i've "fixed" the issue. More coming later.
EDIT:
In order to "fix" my issue, I basically added a new WCF service to my application, and had it implement my previous interface, I then copied all the code from my original service and when I tweaked the .config file (to look pretty much like the one posted in the question), everything worked fine.
Ofcourse, I know, like we all know, that there is no magic here, that there must be some discrepancy. This is when I noticed/remembered, that after I had created my original service, called "BIMIntegrationService.svc", I had decided that this was too long of a name, so I renamed/refactored my class to "BIMIntegrationWS". Doing this, however, does not change the name of the service file (and therefore the name of the file in the http:// address).
Long story short, I made 2 changes to my .config and everything worked:
1) I changed:
<service name="BIMIntegrationWS.BIMIntegrationService" behaviorConfiguration="metadataBehavior">
to
<service name="BIMIntegrationWS.BIMIntegrationWS" behaviorConfiguration="metadataBehavior">
After running the service like this, I got an error (a helpful one this time) complaining that if multipleSiteBindings was enabled, the endpoint address had to be relative. So:
2) I set that to false (because I don't remember why it was in there in the first place) and everything worked fine.
I guess I should have taken a hint when it seemed like my web service was not using my "service" element at all. :\
EDIT 2:
Actually, you can see in my second comment, in the original question, that the auto-generated tag was pointing to: , as opposed to "BIMIntegrationService".
That should have given it away.
I doubt many other people will have this same issue, but just in case.
I've had the same trouble; I've gotten everything configured correctly (even copied the code from a previous service I have running) and yet no change on allowing the service to expose metadata. yet, if I make a spelling error, parse error, etc. to the app.config I'm given exceptions telling me to correct the problem (which tells me the service is reading the config, just disregarding it.
I was able to bypass it by generating the config settings in the host application:
System.ServiceModel.Description.ServiceMetadataBehavior smb = new System.ServiceModel.Description.ServiceMetadataBehavior();
smb.HttpGetEnabled = true;
ServiceBase host = new Servicebase(typeof(MyService), new Uri("http://localhost:1234/"));
host.Description.Behaviors.Add(smb);
host.Open();
...
host.Close();
Basically allow the code to override and push the config file changes i wanted applied. I know it's not ideal, but I was exposing the service through a windows service which made this do-able. if you do get your problem resolved, please pass along the solution though as I'd be curious to know why (at least in yours, if not both our cases) it's failing.

Correct way to make datasources/resources a deploy-time setting

I have a web-app that requires two settings:
A JDBC datasource
A string token
I desperately want to be able to deploy one .war to various different containers (jetty,tomcat,gf3 minimum) and configure these settings at application level within the container.
My code does this:
InitialContext ctx = new InitialContext();
Context envCtx = (javax.naming.Context) ctx.lookup("java:comp/env");
token = (String)envCtx.lookup("token");
ds = (DataSource)envCtx.lookup("jdbc/datasource")
Let's assume I've used the glassfish management interface to create two jdbc resources: jdbc/test-datasource and jdbc/live-datasource which connect to different copies of the same schema, on different servers, different credentials etc. Say I want to deploy this to glassfish with and point it at the test datasource, I might have this in my sun-web.xml:
...
<resource-ref>
<res-ref-name>jdbc/datasource</res-ref-name>
<jndi-name>jdbc/test-datasource</jndi-name>
</resource-ref>
...
but
sun-web.xml goes inside my war, right?
surely there must be a way to do this through the management interface
Am I even trying to do the right thing? Do other containers make this any easier? I'd be particularly interested in how jetty 7 handles this since I use it for development.
EDIT Tomcat has a reasonable way to do this:
Create $TOMCAT_HOME/conf/Catalina/localhost/webapp.xml with:
<?xml version="1.0" encoding="UTF-8"?>
<Context antiResourceLocking="false" privileged="true">
<!-- String resource -->
<Environment name="token" value="value of token" type="java.lang.String" override="false" />
<!-- Linking to a global resource -->
<ResourceLink name="jdbc/datasource1" global="jdbc/test" type="javax.sql.DataSource" />
<!-- Derby -->
<Resource name="jdbc/datasource2"
type="javax.sql.DataSource"
auth="Container"
driverClassName="org.apache.derby.jdbc.EmbeddedDataSource"
url="jdbc:derby:test;create=true"
/>
<!-- H2 -->
<Resource name="jdbc/datasource3"
type="javax.sql.DataSource"
auth="Container"
driverClassName="org.h2.jdbcx.JdbcDataSource"
url="jdbc:h2:~/test"
username="sa"
password=""
/>
</Context>
Note that override="false" means the opposite. It means that this setting can't be overriden by web.xml.
I like this approach because the file is part of the container configuration not the war, but it's not part of the global configuration; it's webapp specific.
I guess I expect a bit more from glassfish since it is supposed to have a full web admin interface, but I would be happy enough with something equivalent to the above.
For GF v3, you may want to try leveraging the --deploymentplan option of the deploy subcommand of asadmin. It is discussed on the man page for the deploy subcommand.
We had just this issue when migrating from Tomcat to Glassfish 3. Here is what works for us.
In the Glassfish admin console, configure datasources (JDBC connection pools and resources) for DEV/TEST/PROD/etc.
Record your deployment time parameters (in our case database connect info) in properties file. For example:
# Database connection properties
dev=jdbc/dbdev
test=jdbc/dbtest
prod=jdbc/dbprod
Each web app can load the same database properties file.
Lookup the JDBC resource as follows.
import java.sql.Connection;
import javax.sql.DataSource;
import java.sql.SQLException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
/**
* #param resourceName the resource name of the connection pool (eg jdbc/dbdev)
* #return Connection a pooled connection from the data source
* associated with resourceName
* #throws NamingException will be thrown if resource name is not found
*/
public Connection getDatabaseConnection(String resourceName)
throws NamingException, SQLException {
Context initContext = new InitialContext();
DataSource pooledDataSource = (DataSource) initContext.lookup(resourceName);
return pooledDataSource.getConnection();
}
Note that this is not the usual two step process involving a look up using the naming context "java:comp/env." I have no idea if this works in application containers other than GF3, but in GF3 there is no need to add resource descriptors to web.xml when using the above approach.
I'm not sure to really understand the question/problem.
As an Application Component Provider, you declare the resource(s) required by your application in a standard way (container agnostic) in the web.xml.
At deployment time, the Application Deployer and Administrator is supposed to follow the instructions provided by the Application Component Provider to resolve external dependencies (amongst other things) for example by creating a datasource at the application server level and mapping its real JNDI name to the resource name used by the application through the use of an application server specific deployment descriptor (e.g. the sun-web.xml for GlassFish). Obviously, this is a container specific step and thus not covered by the Java EE specification.
Now, if you want to change the database an application is using, you'll have to either:
change the mapping in the application server deployment descriptor - or -
modify the configuration of the existing datasource to make it points on another database.
Having an admin interface doesn't really change anything. If I missed something, don't hesitate to let me know. And just in case, maybe have a look at this previous answer.