Writing your own logging framework is the perfect
coding crime.
Group items matching
in title, tags, annotations or url
1More
9More
[JavaSpecialists 177] - Logging Part 3 of 3 - 0 views
-
-
Writing your own logging framework is the perfect coding crime
-
Even the Sun engineers fell into this trap. Prior to Java 4, we had a perfectly good logging framework in Log4J. However, instead of adopting this into the standard Java distribution, we ended up with java.util.logging. There are lots of Java logging frameworks available, even meta-logging frameworks like SLF4J and Jakarta Commons. These are supposed to abstract the logging frameworks so you can change the implementation without touching your code.
- ...5 more annotations...
-
Logging Levels
-
In Log4J for example, we have six default levels, FATAL, ERROR, WARNING, INFO, DEBUG and TRACE.
-
Since it is tricky assigning the correct levels in our code, we should regularly do code reviews with specific emphasis on logging levels.
-
We should be able to adjust the log levels of our individual components at runtime without restarting our application.
-
Silent Operation
-
Writing your own logging framework is the perfect coding crime. If you can convince your manager to put it on the project plan, you are guaranteed to have success. At the end of each day, you will go home feeling happy and satisfied. It will feel like you are doing something creative. You will get the intellectual stimulation without the risk of failure. Even the Sun engineers fell into this trap. Prior to Java 4, we had a perfectly good logging framework in Log4J. However, instead of adopting this into the standard Java distribution, we ended up with java.util.logging. There are lots of Java logging frameworks available, even meta-logging frameworks like SLF4J and Jakarta Commons. These are supposed to abstract the logging frameworks so you can change the implementation without touching your code. http://www.javaspecialists.eu/archive/Issue177.html
1More
SLF4J - 0 views
-
The Simple Logging Facade for Java or (SLF4J) serves as a simple facade or abstraction for various logging frameworks, e.g. java.util.logging, log4j and logback, allowing the end user to plug in the desired logging framework at deployment time. Before you start using SLF4J, we highly recommend that you read the two-page SLF4J user manual. In case you wish to migrate your Java source files to SLF4J, consider our migrator tool which can migrate your project into SLF4J in minutes. In case an externally-maintained component you depend on uses a logging API other than SLF4J, such as commons logging, log4j or j.u.l, have a look at SLF4J's binary-support for legacy APIs.
8More
JDBC 4.0 Enhancements in Java SE 6 - 0 views
-
In JDBC 4.0, we no longer need to explicitly load JDBC drivers using Class.forName(). When the method getConnection is called, the DriverManager will attempt to locate a suitable driver from among the JDBC drivers that were loaded at initialization and those loaded explicitly using the same class loader as the current application.
-
Auto-loading of JDBC driver class
-
Service Provider mechanism (SPM).
- ...4 more annotations...
-
META-INF/services directory.
-
META-INF/services/java.sql.Driver.
-
java.sql.Driver.
-
the META-INF/services/java.sql.Drive
-
JDBC 4.0 Enhancements in Java SE 6 Java Platform, Standard Edition (Java SE) version 6 (code name Mustang), is currently in its second beta release and is scheduled to be delivered in October of this year. Java SE 6 includes several enhancements to the Java Database Connectivity (JDBC) API. These enhancements will be released as JDBC version 4.0. The main objectives of the new JDBC features are to provide a simpler design and better developer experience. This article provides an overview of the JDBC 4.0 enhancements and what benefits they offer to enterprise Java developers. We will explore the new JDBC features with the help of a sample loan processing application using Apache Derby as the back-end database.
125More
Organize Projects - Google Web Toolkit - Google Code - 0 views
-
com.google.gwt.gears.Gears
-
-
two ways to approach loading them
-
nclude each module with a separate <script> tag
- ...118 more annotations...
-
Create a top level module XML definition
-
Compile the top level module
-
the second approach will lead to much better end-user performance
-
each module has to be downloaded separately by the end-user's browser
-
each module will contain redundant copies of GWT library
-
conflict with each other during event handling
-
Linkers are divided into three categories, PRE, POST, and PRIMARY
-
one primary linker is run for a compilation
-
everal linkers are provided by Core.gwt.xml, which is automatically inherited by User.gwt.xml.
-
monolithic JavaScript file.
-
cross-site deployment model.
-
standard iframe-based
-
<add-linker name="xs" />
-
The GWT compiler
-
packaging its output with the Linker subsystem
-
responsible for the final packaging of the JavaScript code
-
providing a pluggable bootstrap mechanism
-
re-use an existing Java API for a GWT project,
-
<super-source>
-
"re-root" a source path
-
to emulate part of the JRE not implemented by GWT
-
tells the compiler to add all subfolders of com/example/myproject/jre/
-
to the source path
-
com/google/myproject/gwt/jre/java/util/UUID.java
-
most commonly used elements in the module XML file.
-
<inherits name="
-
herits all the settings from the specified module
-
<entry-point class=
-
Entry points are all compiled into a single codebase
-
when the onModuleLoad() of your first entry point finishes, the next entry point is called immediately.
-
Any number of entry-point classes can be added
-
<source path="
-
resources get copied into the output directory during a GWT compile.
-
client subpackage is implicitly added to the source path
-
<public path="path" />
-
treated as a publicly-accessible resource.
-
resources get copied into the output directory
-
the public subpackage is implicitly added to the public
-
<servlet
-
For RPC, this element loads a servlet class
-
mounted at the specified URL path
-
path=
-
-
class="
-
-
URL path should be absolute
-
@RemoteServiceRelativePath attribute
-
you must configure a WEB-INF/web.xml in your war directory to load any servlets needed.
-
n development mode,
-
<script src="
-
external JavaScrip
-
<stylesheet src="
-
Extends the set of values
-
for an existing client property
-
<replace-with-class>
-
<generate-with-class>
-
<when-property-is
-
three different types of predicates are
-
<when-type-assignable
-
<when-type-is
-
<all>
-
<any>
-
<none>
-
GWT libraries are organized into modules
-
you want to inherit at least the User module
-
contains all the core GWT functionality
-
including the EntryPoint class
-
widgets and panels
-
History feature
-
Internationalization
-
DOM programming, and more
-
Low-level HTTP
-
Use the following syntax to cause an external JavaScript file to be loaded
-
before your module entry point is called.
-
as if you had included it explicitly using the HTML <script
-
loaded before your onModuleLoad() is called.
-
all included scripts will be loaded when your application starts, in the order in which they are declared.
-
associate external CSS files with your module
-
GWT.getModuleBaseURL() + "foo.css" in client code
-
module's public path
-
useful when
-
inheritance makes resource inclusion particularly convenient.
-
If you wish to create a reusable library that relies upon particular stylesheets or JavaScript files, you can be sure that clients
-
see the documentation for FileSet for a general overview
-
<public>
-
<super-source>
-
<source>
-
includes
-
excludes
-
defaultexcludes
-
casesensitive
-
By default, the patterns listed here are excluded.
-
defaultexcludes is true
-
<script src='myApp/myApp.nocache.js'></script>
-
<script> tags always block evaluation of the page
-
<img> tags do not block page evaluation
-
two simultaneous connections
-
The body.onload() event will only fire once all external resources are fetched, including images and frames.
-
GWT selection script
-
like a normal script tag
-
but the compiled script will be fetched asynchronously.
-
Parsing is blocked until externalScriptZero.js is done fetching and evaluating.
-
myApp/myApp.nocache.js completes
-
the compiled scrip
-
(<hashname>.cache.html
-
begins fetching in a hidden IFRAME (this is non-blocking).
-
onModuleLoad() is not called yet, as we're still waiting on externalScriptOne.js
-
body.onload() fires
-
onload='alert("w00t!")
-
-
put the GWT selection script as early as possible
-
because it won't block any other script requests
-
<img> tags are not guaranteed to be done loading when onModuleLoad() is called
-
<script> tags are guaranteed to be done loading when onModuleLoad() is called
-
multiple EntryPoints
-
will all be called in sequence as soon as that module (and the outer document) is ready
-
multiple GWT modules within the same page
-
each module's EntryPoint will be called as soon as both that module and the outer document is ready
-
EntryPoints are not guaranteed to fire at the same time
-
or in the same order
-
in which their selection scripts were specified in the host page
1More
Apache Commons Daemon : Java based daemons or services - 0 views
-
"Since 1994, the Java programming language evolved and became a valid tool to develop reliable and performant server applications as opposed to just applets and client applications. The major disadvantage of the Java platform is that still today the only portable way to start a Java application relies on a single point of entry: the public static void main(String[]) method. Having a single-point of entry is a valid solution for client applications, where interactively a user can command to the application to quit (which can terminate the Virtual Machine process at calling the System.exit(int) method), but in those cases where the application is not interactive (server applications) there is currently no portable way to notify the Virtual Machine of its imminent shutdown. A server application written in Java might have to perform several tasks before being able to shutdown the Virtual Machine process. For example in the case of a Servlet container, before the VM process is shut down, sessions might need to be serialized to disk, and web applications need to be destroyed. One common solution to this problem is to create (for example) a ServerSocket and wait for a particular message to be issued. When the message is received, all operations required to shut down the server applications are performed and at the end the System.exit method is called to terminate the Virtual Machine process. This method however, has several disadvantages and risks: In case of a system-wide shutdown, the Virtual Machine process may be shut down directly by the operating system without notifying the running server application. If an attacker finds out the shutdown message to send to the server and discovers a way to send this message, he can easily interrupt the server's operation, bypassing all the security restrictions implemented in the operating system. Most multi-user operating systems already have a way in which server applications are started and stopped. Under Unix based
1More
Using AspectJ to log all methods parameters and return values during application runtime - 8 views
-
AspectJ is an aspect-oriented extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become the widely used de-facto standard for AOP by emphasizing simplicity and usability for end users. It uses Java-like syntax and has included IDE integrations for displaying crosscutting structure since its initial public release in 2001. In this article we will describe how we can use AspectJ to do the logging job for all methods parameters and methods return values in a Java application
1More
shared by krowddigital on 09 Feb 22
- No Cached
Mobile App Development Services in Melbourne - 1 views
www.krowd.com.au/mobile-app-development.php
Mobile App Development Services Mobile App iOS App Android App
shared by krowddigital on 09 Feb 22
- No Cached
-
We provide end-to-end mobile app development service that cover the entire development cycle. UI/ UX Design, Development, QA and more. Visit Website!
1More
Spring to Java EE - A Migration Experience | OcpSoft - 0 views
-
Does it all make sense now? Do you know how to solve every problem? Probably not, but when it comes right down to it, using Java EE can be even simpler than using Spring, and take much less time. You just have to find the right guides and the right documentation (which is admittedly a severe sore-spot of Java EE; the documentation is still a work in progress, but is getting much better, save blogs like this one.) You have to turn to a vendor like JBoss, or IBM in order to get the use-case driven documentation you need, and they do have documentation, it's just a matter of finding it. Seam 3 in particular strives to give extensive user-documentation, hopefully making things much simpler to adopt, and easier to extend. The main purpose of this article was not to bash Spring, although I may have taken that tone on occasion just for contrast and a little bit of fun. Both Spring and Java EE are strongly engineered and have strong foundations in practical use, but if you want a clean programming experience right out of the box - use Java EE 6 on JBoss Application Server 6 - JBoss Tools - and Eclipse. I will say, though, that the feeling I've gotten from the Spring forums vs the Java EE forums, is that there are far many more people willing to help you work through Java EE issues, and more available developers of the frameworks themselves to actually help you than there are on the Spring side. The community for Java EE is much larger, and much more supportive (from my personal experience.) In the end, I did get my application migrated successfully, and despite these issues (from which I learned a great deal,) I am still happy with Java EE, and would not go back to Spring! But I do look forward to further enhancements from the JBoss Seam project, which continue to make developing for Java EE simpler and more fun. Don't believe me? Try it out. Find something wrong? Tell me. Want more? Let me know what you want to hear.
13More
The ASF Resigns From the JCP Executive Committee - 0 views
-
Oracle provided the EC with a Java SE 7 specification request and license that are self-contradictory, severely restrict distribution of independent implementations of the spec, and most importantly, prohibit the distribution of independent open source implementations of the spec. Oracle has refused to answer any reasonable and responsible questions from the EC regarding these problems.
-
In the phrase "fail to uphold their responsibilities under the JSPA", we are referring to Oracle's refusal to provide the ASF's Harmony project with a TCK license for Java SE that complies with Oracle's obligations under the JSPA as well as public promises made to the Java community by officers of Sun Microsystems (recently acquired by Oracle.)
-
it should be noted that the majority of the EC members, including Oracle, have publicly stated that restrictions on distribution such as those found in the Java SE 7 license have no place in the JCP - and two distinguished individual members of the EC, Doug Lea and Tim Peierls, both have resigned in protest over the same issue.
- ...9 more annotations...
-
By approving Java SE 7, the EC has failed on both counts : the members of the EC refused to stand up for the rights of implementers, and by accepting Oracle's TCK license terms for Java SE 7, they let the integrity of the JCP's licensing structure be broken.
-
The Apache Software Foundation concludes that that JCP is not an open specification process
-
and finally, the EC is unwilling or unable to assert the basic power of their role in the JCP governance process
-
In short, the EC and the Java Community Process are neither.
-
To that end, our representative has informed the JCP's Program Management Office of our resignation, effective immediately. As such, the ASF is removing all official representatives from any and all JSRs. In addition, we will refuse any renewal of our JCP membership and, of course, our EC position.
-
Okay ! Java's privatized now... What now ?
-
Thank god I moved off Java in time. Suddenly Oracle is the new Death Star, replacing Microsoft.
-
This is a sad, sad day in the Java community. I hoped that Oracle would back-peddle and realize the folly of their ways. Now Java will be to Oracle what .NET is to Microsoft and it will be the death of Java as we know it.
-
Posibly in few years we'll see Apache as a new Sun for "Java", followed by Eclipse, Google, etc... I hope this is a great movement done by Apache for the community. We'll see... The objetive of Oracle are Enterprises that cannot move from Java because of hight investments, it will earn a lot of money from them. Oracle ignores the community because is not going to pay for (expensive, as all the rest of Oracle products) licenses... We'll se...
-
The Apache Software Foundation has resigned its seat on the Java SE/EE Executive Committee. Apache has served on the EC for the past 10 years, winning the JCP "Member of the Year" award 4 times, and recently was ratified for another term with support from 95% of the voting community. Further, the project communities of the ASF, home to Apache Tomcat, Ant, Xerces, Geronimo, Velocity and nearly a 100 mainstay java components have implemented countless JSRs and serve on and contribute to many of the JCPs technical expert groups. We'd like to provide some explanation to the community as to why we're taking this significant step.
