Take backup - but without Stupidity !!!

Please take backup ur code on regular basis otherwise.... :( I got bad sector on my HDD drive ( that contained the OS and my coding folders too... ) suddenly and i discover me that i took my backup on Desktop - as a result guess what happened? All of my codes with my backup turns into my bad dreams :( I tried with several recovery utilities for more than a week but no positive results... and i found some of my important task was in jar formatted - i needed to recover the class files to code - so i download DJ Decompiler - ( i used it before ... one good tool....) but after downloading.... i could not use it any more ..... ( of course for free ) - However i download and this simply saved my time and make me :)

If you need to convert your class files to source (.java) file simply download and enjoy.

Happy Coding..... :)

Tasks....

Search for handsets support AT commands
http://www.allthemobile.com/search/?qr=nokia+AT+command+support+sets

http://www.developershome.com/sms/freeLibForSMS.asp

Check compatibility
http://www.developershome.com/sms/cpmsCommand.asp




Responsibilities:
Lead and oversee the design of new, Java / J2EE / Java EE and SOA based solutions.
Perform Research and Development into the very latest in Internet-based technologies, methodologies, architectures and industry trends.
Analyze code to find causes of errors and revise code. Test code using structured testing methodology and confirms programs meet specification.
Convert designs and specifications into code.
Write and maintain technical specifications, documentation to describe program development, coding, testing, changes, and corrections, installation and operation of developed software.
Provide technical assistance by responding to inquiries from other stakeholders.

Requirements:

A strong interest in researching, making recommendations and implementing new web related tools/technologies is highly preferred. The candidate must be able to code, debug and test application programs utilizing JAVA and web-based programming tools. Having hands on experience in HTML, CSS etc i.e. web technologies will be an advantage. Candidates must be committed to exacting quality standards; extensive unit and integration test experience. Candidates must have experience working successfully in a close team environment.
2+ years experience designing and deploying Java / J2EE / Java EE-based solutions on behalf of complex, integrated, business environments.
Experience designing and exposing re-usable Service Orientated Architecture (SOA) based solutions.
Deep knowledge of XML, Apache Tomcat, JBoss, Java Server Pages (JSP), HTTP, and Servlets.
Proven and extensive experience designing solutions using the Apache Struts Framework (for Java EE) and Apache Axis Framework (for Web Services).
Possesses a strong background in Object-Oriented (OO) system design.
Experience with iterative software design, prototyping and methodologies.
Demonstrable experience with Intellij IDEA or similar product.
Experience with software build/deployment frameworks (such as MAKE, ANT, MAVEN, etc.) and unit test frameworks (such as JUNIT).
Experience performing source control with Perforce or similar product.
Excellent written and verbal communication skills. Presentation skills and the demonstrable ability to discuss technical subjects with personnel - at all levels - is a must.
Highly analytical, pro-active and detail oriented.

Performace Does Matter

Performance Tuning !!!

Tune using EJB3QL

Oracle Driver Missing for Reports

Check Oracle Driver Missing Info

1. java.lang.ClassNotFoundException: oracle.jdbc.driver.OracleDriver

Hi everybody

I'm new in java Platform and i have problems trying to load a JDBC driver using Class.forname, but JVM can not find it. I configured classpath enviroment path pointig to libraries

OS: Windows XP
Java Version 1.6
IDE Eclipse 3.2.2

classpath = .;C:\Program Files\Altova\xmlspy\XMLSpyInterface.jar;c:\program files\Microsoft SQL Server 2000 Driver for JDBC\lib\msbase.jar;c:\program files\Microsoft SQL Server 2000 Driver for JDBC\lib\msutil.jar;c:\program files\Microsoft SQL Server 2000 Driver for JDBC\lib\mssqlserver.jar;D:\oracle\ora92\jdbc\lib\ classes12.zip


java.lang.ClassNotFoundException: oracle.jdbc.driver.OracleDriver
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at bpos.Db.Conectar(Db.java:20)
at bpos.Process.main(Process.java:19)


Can anybody help me about this? It will appreciate.

Leo

2. Hello Leo,

Try putting the full path to the Oracle classes12.zip file at the front of the CLASSPATH. Also remove the extra space between the \ and classes12.zip.

Before you test with an app, ensure the driver returns version information by running this command on the command line:

java oracle.jdbc.driver.OracleDriver

If that command does not work, you still have environment problems and need to revisit before you test with the app.

Best regards,
Netrista Khatam
Technical Services Manager
OpenLink Product Support


3. Hi Netrista.. thank you for your help.. I checked my enviroment variables and i didn't find problems. I think that was copy paste mistake. I put first the oracle driver library reference into the classpath enviroment variable

C:\>echo %classpath%
.;D:\oracle\ora92\jdbc\lib\classes12.zip;C:\Progra m Files\Altova\xmlspy\XMLSpyInterface.jar;c:\program files\Microsoft SQL Server 2000 Driver for JDBC\lib\msbase.jar;c:\program files\Microsoft SQL Server 2000 Driver for JDBC\lib\msutil.jar;c:\program files\Microsoft SQL Server 2000 Driver for JDBC\lib\mssqlserver.jar

I performed your suggested command and i couldn't get the version of each class i'm trying to use

C:\>java oracle.jdbc.driver.OracleDriver
Exception in thread "main" java.lang.NoSuchMethodError: main

C:\>java com.microsoft.jdbc.sqlserver.SQLServerDriver
null

any other thing that it could be used? thanks!

Leo


4. Hello Leo,

This is what I would recommend:

1. Verify that the following path is correct:

D:\oracle\ora92\jdbc\lib\classes12.zip

2. Insure no permissions issues exist on that file or directory structure, which is unlikely since it is Windows.

3. Run this command to get your java version:

java -version

4. Insure that the java version of the JVM/JDK that you have installed on Windows is compatible with the requirements of the driver.

Can you state whether or not you can use the other JDBC drivers to get a connection using the application, even though they error on the commandline with DOS. I've seen that before, so it's important to ascertain whether the app connectivity issue is specific to Oracle or generalized to all JDBC connections.


Best regards,
Netrista Khatam
Technical Services Manager
OpenLink Product Support

5. Fixed!

Thank you very much.

The classpath was correct. I proved on command line and it worked correctly. So i have to change my approach looking for into my IDE project definition parameters. I' m using Eclipse and i found that i have to define a classpath for the project.

Ups! I'm new in Eclipse too.. and i forgot mention it. Your description of the solution helped me to find the final solution. Thank you!

Leo

Quote:

Try putting the full path to the Oracle classes12.zip file at the front of the CLASSPATH. Also remove the extra space between the \ and classes12.zip.

Before you test with an app, ensure the driver returns version information by running this command on the command line:

java oracle.jdbc.driver.OracleDriver

If that command does not work, you still have environment problems and need to revisit before you test with the app.

Best regards,
Netrista Khatam
Technical Services Manager
OpenLink Product Support

Customize JBoss log file size

Customize JBoss log file size

Some of the logging configuration changes that you might want to make include:
• Specifying a rolling log file.
• Limiting the amount of logging produced.
• Adding logging for your application.
• Defining a new log file.

Each of these topics is covered in the following text.

Rolling the server log file
The server.log file is created new each time the server is launched, and grows until the server is stopped, or until midnight. This behavior, while appropriate for a development environment, is not optimal for a production environment. In production you should specify a rolling log file, which when it reaches a certain size creates a new log file. Listing 1 shows how you can change the appender for the server.log file to create at most 20 log files of 10 megabytes (MB) in size each. All of the changes are highlighted.

Listing 1 Defining a rolling log appender

01.<log4j:...>

02. <appender name="FILE"

03. class="org.jboss.logging.appender.RollingFileAppender"> #1

04. <errorHandler .../>

05. <param name="File" value="${jboss.server.log.dir}/server.log"/> #2

06. <param name="Append" value="true"/> #3

07. <param name="MaxFileSize" value="10MB"/> #4

08. <param name="MaxBackupIndex" value="20"/> #5

09. <layout .../>

10. appender>

11. ...

12.log4j>

#1: Changed to use the rolling appender
#2: Location of log file
#3: Append to existing file on startup
#4: Limit log file size to 10MB
#5: Keep only the last 20 log files

We did not change the errorHandler or layout settings from the default. By the way, the various appenders defined in the org.jboss.logging.appender package are simple subclasses of the Log4J appenders defined in the org.apache.log4j package that automatically create the server/xxx/log directory.
The system property jboss.server.log.dir defines the location of the log file (#2).

Generic Data Access Objects

	Generic Data Access Objects The DAO interfaces An implementation with Hibernate Preparing DAOs with factories Preparing DAOs with manual dependency injection Preparing DAOs with lookup Writing DAOs as managed EJB 3.0 components A Better typed Generic DAO? You decide! This is a pattern for Data Access Objects with JDK 5.0, from the CaveatEmptor example application. It is also explained in the book Java Persistence with Hibernate. Two links you might find useful: Sessions and transactions and Open Session in View. This time I based the DAO example on interfaces. Tools like Hibernate already provide database portability, so persistence layer portability shouldn't be a driving motivation for interfaces. However, DAO interfaces make sense in more complex applications, when several persistence services are encapsulate in one persistence layer. I'd say that you should use Hibernate (or Java Persistence APIs) directly in most cases, the best reason to use an additional DAO layer is higher abstraction (e.g. methods like getMaximumBid() instead of session.createQuery(...) repeated a dozen times). The DAO interfaces I use one interface per persistent entity, with a super interface for common CRUD functionality: public interface GenericDAO { T findById(ID id, boolean lock); List findAll(); List findByExample(T exampleInstance); T makePersistent(T entity); void makeTransient(T entity); } You can already see that this is going to be a pattern for a state-oriented data access API, with methods such as makePersistent() and makeTransient(). Furthermore, to implement a DAO you have to provide a type and an identifier argument. As for most ORM solutions, identifier types have to be serializable. The DAO interface for a particular entity extends the generic interface and provides the type arguments: public interface ItemDAO extends GenericDAO { public static final String QUERY_MAXBID = "ItemDAO.QUERY_MAXBID"; public static final String QUERY_MINBID = "ItemDAO.QUERY_MINBID"; Bid getMaxBid(Long itemId); Bid getMinBid(Long itemId); } We basically separate generic CRUD operations and actual business-related data access operations from each other. (Ignore the named query constants for now, they are convenient if you use annotations.) However, even if only CRUD operations are needed for a particular entity, you should still write an interface for it, even it it is going to be empty. It is important to use a concrete DAO in your controller code, otherwise you will face some refactoring once you have to introduce specific data access operations for this entity. An implementation with Hibernate An implementation of the interfaces could be done with any state-management capable persistence service. First, the generic CRUD implementation with Hibernate: public abstract class GenericHibernateDAO implements GenericDAO { private Class persistentClass; private Session session; public GenericHibernateDAO() { this.persistentClass = (Class) ((ParameterizedType) getClass() .getGenericSuperclass()).getActualTypeArguments()[0]; } @SuppressWarnings("unchecked") public void setSession(Session s) { this.session = s; } protected Session getSession() { if (session == null) throw new IllegalStateException("Session has not been set on DAO before usage"); return session; } public Class getPersistentClass() { return persistentClass; } @SuppressWarnings("unchecked") public T findById(ID id, boolean lock) { T entity; if (lock) entity = (T) getSession().load(getPersistentClass(), id, LockMode.UPGRADE); else entity = (T) getSession().load(getPersistentClass(), id); return entity; } @SuppressWarnings("unchecked") public List findAll() { return findByCriteria(); } @SuppressWarnings("unchecked") public List findByExample(T exampleInstance, String[] excludeProperty) { Criteria crit = getSession().createCriteria(getPersistentClass()); Example example = Example.create(exampleInstance); for (String exclude : excludeProperty) { example.excludeProperty(exclude); } crit.add(example); return crit.list(); } @SuppressWarnings("unchecked") public T makePersistent(T entity) { getSession().saveOrUpdate(entity); return entity; } public void makeTransient(T entity) { getSession().delete(entity); } public void flush() { getSession().flush(); } public void clear() { getSession().clear(); } /** * Use this inside subclasses as a convenience method. */ @SuppressWarnings("unchecked") protected List findByCriteria(Criterion... criterion) { Criteria crit = getSession().createCriteria(getPersistentClass()); for (Criterion c : criterion) { crit.add(c); } return crit.list(); } } There are some interesting things in this implementation. First, it clearly needs a Session to work, provided with setter injection. You could also use constructor injection. How you set the Session and what scope this Session has is of no concern to the actual DAO implementation. A DAO should not control transactions or the Session scope. We need to suppress a few compile-time warnings about unchecked casts, because Hibernate's interfaces are JDK 1.4 only. What follows are the implementations of the generic CRUD operations, quite straightforward. The last method is quite nice, using another JDK 5.0 feature, varargs. It helps us to build Criteria queries in concrete entity DAOs. This is an example of a concrete DAO that extends the generic DAO implementation for Hibernate: public class ItemDAOHibernate extends GenericHibernateDAO implements ItemDAO { public Bid getMaxBid(Long itemId) { Query q = getSession().getNamedQuery(ItemDAO.QUERY_MAXBID); q.setParameter("itemid", itemId); return (Bid) q.uniqueResult(); } public Bid getMinBid(Long itemId) { Query q = getSession().getNamedQuery(ItemDAO.QUERY_MINBID); q.setParameter("itemid", itemId); return (Bid) q.uniqueResult(); } } Another example which uses the findByCriteria() method of the superclass with variable arguments: public class CategoryDAOHibernate extends GenericHibernateDAO implements CategoryDAO { public Collection findAll(boolean onlyRootCategories) { if (onlyRootCategories) return findByCriteria( Expression.isNull("parent") ); else return findAll(); } } Preparing DAOs with factories We could bring it all together in a DAO factory, which not only sets the Session when a DAO is constructed but also contains nested classes to implement CRUD-only DAOs with no business-related operations: public class HibernateDAOFactory extends DAOFactory { public ItemDAO getItemDAO() { return (ItemDAO)instantiateDAO(ItemDAOHibernate.class); } public CategoryDAO getCategoryDAO() { return (CategoryDAO)instantiateDAO(CategoryDAOHibernate.class); } public CommentDAO getCommentDAO() { return (CommentDAO)instantiateDAO(CommentDAOHibernate.class); } public ShipmentDAO getShipmentDAO() { return (ShipmentDAO)instantiateDAO(ShipmentDAOHibernate.class); } private GenericHibernateDAO instantiateDAO(Class daoClass) { try { GenericHibernateDAO dao = (GenericHibernateDAO)daoClass.newInstance(); dao.setSession(getCurrentSession()); return dao; } catch (Exception ex) { throw new RuntimeException("Can not instantiate DAO: " + daoClass, ex); } } // You could override this if you don't want HibernateUtil for lookup protected Session getCurrentSession() { return HibernateUtil.getSessionFactory().getCurrentSession(); } // Inline concrete DAO implementations with no business-related data access methods. // If we use public static nested classes, we can centralize all of them in one source file. public static class CommentDAOHibernate extends GenericHibernateDAO implements CommentDAO {} public static class ShipmentDAOHibernate extends GenericHibernateDAO implements ShipmentDAO {} } This concrete factory for Hibernate DAOs extends the abstract factory, which is the interface we'll use in application code: public abstract class DAOFactory { /** * Creates a standalone DAOFactory that returns unmanaged DAO * beans for use in any environment Hibernate has been configured * for. Uses HibernateUtil/SessionFactory and Hibernate context * propagation (CurrentSessionContext), thread-bound or transaction-bound, * and transaction scoped. */ public static final Class HIBERNATE = org.hibernate.ce.auction.dao.hibernate.HibernateDAOFactory.class; /** * Factory method for instantiation of concrete factories. */ public static DAOFactory instance(Class factory) { try { return (DAOFactory)factory.newInstance(); } catch (Exception ex) { throw new RuntimeException("Couldn't create DAOFactory: " + factory); } } // Add your DAO interfaces here public abstract ItemDAO getItemDAO(); public abstract CategoryDAO getCategoryDAO(); public abstract CommentDAO getCommentDAO(); public abstract ShipmentDAO getShipmentDAO(); } Note that this factory example is suitable for persistence layers which are primarily implemented with a single persistence service, such as Hibernate or EJB 3.0 persistence. If you have to mix persistence APIs, for example, Hibernate and plain JDBC, the pattern changes slightly. Keep in mind that you can also call session.connection() inside a Hibernate-specific DAO, or use one of the many bulk operation/SQL support options in Hibernate 3.1 to avoid plain JDBC. Finally, this is how data access now looks like in controller/command handler code (pick whatever transaction demarcation strategy you like, the DAO code doesn't change): // EJB3 CMT: @TransactionAttribute(TransactionAttributeType.REQUIRED) public void execute() { // JTA: UserTransaction utx = jndiContext.lookup("UserTransaction"); // JTA: utx.begin(); // Plain JDBC: HibernateUtil.getCurrentSession().beginTransaction(); DAOFactory factory = DAOFactory.instance(DAOFactory.HIBERNATE); ItemDAO itemDAO = factory.getItemDAO(); UserDAO userDAO = factory.getUserDAO(); Bid currentMaxBid = itemDAO.getMaxBid(itemId); Bid currentMinBid = itemDAO.getMinBid(itemId); Item item = itemDAO.findById(itemId, true); newBid = item.placeBid(userDAO.findById(userId, false), bidAmount, currentMaxBid, currentMinBid); // JTA: utx.commit(); // Don't forget exception handling // Plain JDBC: HibernateUtil.getCurrentSession().getTransaction().commit(); // Don't forget exception handling } The database transaction, either JTA or direct JDBC, is started and committed in an interceptor that runs for every execute(), following the Open Session in View pattern. You can use AOP for this or any kind of interceptor that can be wrapped around a method call, see Session handling with AOP. Preparing DAOs with manual dependency injection You don't need to write the factories. You can as well just do this: // EJB3 CMT: @TransactionAttribute(TransactionAttributeType.REQUIRED) public void execute() { // JTA: UserTransaction utx = jndiContext.lookup("UserTransaction"); // JTA: utx.begin(); // Plain JDBC: HibernateUtil.getCurrentSession().beginTransaction(); ItemDAOHibernate itemDAO = new ItemDAOHibernate(); itemDAO.setSession(HibernateUtil.getSessionFactory().getCurrentSession()); UserDAOHibernate userDAO = new UserDAOHibernate(); userDAO.setSession(HibernateUtil.getSessionFactory().getCurrentSession()); Bid currentMaxBid = itemDAO.getMaxBid(itemId); Bid currentMinBid = itemDAO.getMinBid(itemId); Item item = itemDAO.findById(itemId, true); newBid = item.placeBid(userDAO.findById(userId, false), bidAmount, currentMaxBid, currentMinBid); // JTA: utx.commit(); // Don't forget exception handling // Plain JDBC: HibernateUtil.getCurrentSession().getTransaction().commit(); // Don't forget exception handling } The disadvantage here is that the implementation classes (i.e. ItemDAOHibernate and UserDAOHibernate) of the persistence layer are exposed to the client, the controller. Also, constructor injection of the current Session might be more appropriate. Preparing DAOs with lookup Alternatively, call HibernateUtil.getSessionFactory().getCurrentSession() as a fallback, if the client didn't provide a Session when the DAO was constructed: public abstract class GenericHibernateDAO implements GenericDAO { private Class persistentClass; private Session session; public GenericHibernateDAO() { this.persistentClass = (Class) ((ParameterizedType) getClass() .getGenericSuperclass()).getActualTypeArguments()[0]; } public void setSession(Session session) { this.session = session; } protected void getSession() { if (session == null) session = HibernateUtil.getSessionFactory().getCurrentSession(); return session; } ... The controller now uses these stateless data access objects through direct instantiation: // EJB3 CMT: @TransactionAttribute(TransactionAttributeType.REQUIRED) public void execute() { // JTA: UserTransaction utx = jndiContext.lookup("UserTransaction"); // JTA: utx.begin(); // Plain JDBC: HibernateUtil.getCurrentSession().beginTransaction(); ItemDAO itemDAO = new ItemDAOHibernate(); UserDAO userDAO = new UserDAOHibernate(); Bid currentMaxBid = itemDAO.getMaxBid(itemId); Bid currentMinBid = itemDAO.getMinBid(itemId); Item item = itemDAO.findById(itemId, true); newBid = item.placeBid(userDAO.findById(userId, false), bidAmount, currentMaxBid, currentMinBid); // JTA: utx.commit(); // Don't forget exception handling // Plain JDBC: HibernateUtil.getCurrentSession().getTransaction().commit(); // Don't forget exception handling } The only disadvantage of this very simple strategy is that the implementation classes (i.e. ItemDAOHibernate and UserDAOHibernate) of the persistence layer are again exposed to the client, the controller. You can still supply a custom Session if needed (integration test, etc). Each of these methods (factories, manual injection, lookup) for setting the current Session and creating a DAO instance has advantages and drawbacks, use whatever you feel most comfortable with. Naturally, the cleanest way is managed components and EJB 3.0 session beans: Writing DAOs as managed EJB 3.0 components Turn your DAO superclass into a base class for stateless session beans (all your concrete DAOs are then stateless EJBs, they already have a business interface). This is basically a single annotation which you could even move into an XML deployment descriptor if you like. You can then use dependency injection and get the "current" persistence context provided by the container: @Stateless public abstract class GenericHibernateDAO implements GenericDAO { private Class persistentClass; @PersistenceContext private EntityManager em; public GenericHibernateDAO() { setSession( (Session)em.getDelegate() ); } ... You can then cast the delegate of an EntityManager to a Hibernate Session. This only works if you use Hibernate as a Java Persistence provider, because the delegate is the Session API. In JBoss AS you could even get a Session injected directly. If you use a different Java Persistence provider, rely on the EntityManager API instead of Session. Now wire your DAOs into the controller, which is also a managed component: @Stateless public class ManageAuctionController implements ManageAuction { @EJB ItemDAO itemDAO; @EJB UserDAO userDAO; @TransactionAttribute(TransactionAttributeType.REQUIRED) // This is even the default public void execute() { Bid currentMaxBid = itemDAO.getMaxBid(itemId); Bid currentMinBid = itemDAO.getMinBid(itemId); Item item = itemDAO.findById(itemId, true); newBid = item.placeBid(userDAO.findById(userId, false), bidAmount, currentMaxBid, currentMinBid); } } P.S. Credit has to be given to Eric Burke, who first posted the basics for this pattern on his blog. Unfortunately, not even the Google cache is available anymore. A Better typed Generic DAO? You decide! We are missing something on end, since T allows you to "domain-ify" everything! and the Identifier type should ideally match the identifier type of T, but there's no way to do that on the code above. You decide which approach is better. // Our common Model interface that an abstract Domain model will implement and all domain // models will extend. public interface IModel { public abstract ID getId(); public abstract void setId(final ID pId); } // Our generic DAO, NOTE: MODEL's ID type is the same as ID now, which makes sense. // Also model type is more restrictive, dis-allowing all kinds of funky stuff to go in. public abstract class GenericHibernateDAO, ID extends Serializable> implements GenericDAO { private Class persistentClass; private Session session; public GenericHibernateDAO() { // FIXME : I don't like magic number in the code, is there any way to fix 0 to something dynamic? this.persistentClass = (Class) ((ParameterizedType) getClass() .getGenericSuperclass()).getActualTypeArguments()[0]; } public final void setSession(final Session pSession) { this.session = session; } protected void getSession() { if (session == null) session = HibernateUtil.getSessionFactory().getCurrentSession(); return session; } ... In addition, we could add things like: public final String getRootAlias(){ this.getPersistentClass().getSimpleName() + String.valueOf('_'); } Alhough this is not necessary or part of the enhanced version, but when criteria API is in use, this comes in handy. Reference : https://www.hibernate.org/328.html

Portal Links

Portal link

Portal IP Link