Commonly Used Sign- Punctuation and their Name in Perl

perl-sign-punctuation-marks

Commonly Used Sign- Punctuation and their Name in Perl

( => ) Comma Arrow  ( ‘ ’, “ ”, ‘ ‘, ” “ ) à Quotation marks
( $ ) àDollar sign ( ~ ) à Tilde
( % ) àPercent sign ,  ) à Comma
( @ ) à At Sign ( ; ) à Semicolon
( & ) à Ampersand Sign ( : ) à Colon
( / ) à Forward Slash/Slash sign ( , , ) à Dash
( \ )  à Backslash/Slash Sign ( )    à Hyphen-minus
( < )  à Less than Sign ( _ ) àunderscore
( > )  à Greater than sign ( / ) à slash/stroke/solidus
( { } )  àCurly Braces ( * ) à Asterisk
( [  ] ) à Square brackets ( ^ ) à caret
( ( ) )  à Round brackets ( ¦, | ) à vertical bar/broken bar/pipe
( , , ) àprime ( ) à Ditto mark
( ! ) à Exclamation Mark ( ? ) – Question Mark
Tagged : / / / / / / / / / / / / / / / / /

Use of p4 duplicate command | P4 Command Guide

p4-duplicate-command

Use of p4 duplicate command

Problem Area is –
Is there any possibility to rename branch name? as directory rename is possible?

Solution is – p4 duplicate command

What the command ‘p4 duplicate’ was implement to do was create a duplicated revision of a folder as if it always existed. This is explained in the ‘p4 help duplicate’, I have copied below:

Duplicate revisions as if they always existed.  All aspects of
   the source revisions are mirrored into the target revisions,
   including changelist number, date, attributes, and contents.
   The target revision must not already exist, and the target file
must not be opened (for any operation) on any client.

Integration records are duplicated as well.

To rename branch names is possible with the process of a deep rename operation.

p4 duplicate //depot/Jam/MAINds/… //depot/Jam/MAIN/…

The above command will create an exact copy of the branch you’re duplicating including its integration history.

Then the duplication source is not wanted anymore, so you will need to use the obliterate command:

p4 obliterate -y //depot/Jam/MAINds/…

You can find more information about “p4 duplicate” by running the “p4 help duplicate” command.

If you have any further questions please let me know.

Reference –

Perforce Support and

http://maillist.perforce.com/pipermail/perforce-user/2010-November/027364.html

Tagged : / / / / / / / / / / / / / /

Difference between use and require in Perl – use Vs require in perl

perl-use-require-difference

|| use Vs require in perl || What is the difference between use and require?

Except of course that use is evaluated at compile time where as require is evaluated at run time in other word, A use anywhere in the code will be evaluated when the code is run compiled, but require – import’s can only get evaluated when encoutered.

The differences are many and often subtle:

  1. use only expects a bareword, require can take a bareword or an expression
  2. use is evaluated at compile-time, require at run-time
  3. use implicitly calls the import method of the module being loaded, require does not
  4. use excepts arguments in addition to the bareword (to be passed to import), require does not
  5. use does not behave like a function (i.e can’t be called with parens, can’t be used in an expression, etc), whereas require does

do $file is like eval `cat $file`, except the former:
1.1: searches @INC and updates %INC.
1.2: bequeaths an *unrelated* lexical scope on the eval’ed code.

require $file is like do $file, except the former:
2.1: checks for redundant loading, skipping already loaded files.
2.2: raises an exception on failure to find, compile, or execute $file.

require Module is like require “Module.pm”, except the former:
3.1: translates each “::” into your system’s directory separator.
3.2: primes the parser to disambiguate class Module as an indirect object.

use Module is like require Module, except the former:
4.1: loads the module at compile time, not run-time.
4.2: imports symbols and semantics from that package to the current one.

Command to learn more about use and require
> perldoc -f require
> perldoc -f use

Tagged : / / / / / / / /

Why and how to use Jetty in mission-critical production

how-to-use-jetty

This article is a summary of a seminar I had on the topic. If it seems like it’s a continuation of an existing discussion that’s because, to some extent, it is. If you haven’t been discussing exchanging your app server, this article probably isn’t very interesting to you.

By putting the application server inside my application instead of the other way around, I was able to leap tall buildings in a single bound.

The embedded application server

This is how I deploy my sample application to a new test environment (or to production):

  1. mvn install
  2. scp -server/target/-1.0.onejar.jar appuser@appserver:/home/appuser/test-env1/
  3. ssh appuser@appserver “cd /home/appuser/test-env1/ && java -jar -1.0.onejar.jar&”

This require no prior installed software on the appserver (with the exception of the JVM). It requires no prior configuration. Rolling back is a matter of replacing one jar-file with another. Clustering is a matter of deploying the same application several times.

In order to make this work in a real environment, there are a many details you as a developer need to take care of. As a matter of fact, you will have to take responsibility for your operational environment. The good news is that creating a good operational environment is not more time-consuming than trying to cope with the feed and care of a big-a Application Server.

In this scheme every application comes with its own application server in the form of jetty’s jar-files embedded in the deployed jar-file.

The advantages

Why would you want to do something like this?

  • Independent application: If you’ve ever been told that you can’t use Java 1.5 because that would require an upgrade of the application server. And if we upgrade the application server, that could affect someone else adversely. So we need to start a huge undertaking to find out who could possibly be affected.
  • Developer managed libraries: Similar problems can occur with libraries. Especially those that come with the application server. For example: Oracle OC4J helpfully places a preview version of JPA 1.0 first in your classpath. If you want to use Hibernate with JPA 1.0-FINAL, it will mostly work. Until you try to use a annotation that was changed after the preview version (@Discriminator, for example). The general rule is: If an API comes with your app server, you’re better served by staying away from it. A rather bizarre state of affairs.
  • Deployment, configuration and upgrades: Each version of the application, including all its dependencies is packaged into a single jar-file that can be deployed on several application server, or several times on the same application server (with different ports). The configuration is read from a properties-file in the current working directory. On the minus side, there’s no fancy web UI where you can step through a wizard to deploy the application or change the configuration. On the plus side, there is no fancy web UI …. If you’ve used one such web UI, you know what I mean.
  • Continuous deployment: As your maven-repository will contain stand alone applications, creating a continuous deployment scheme is very easy. In my previous environment, a cron job running wget periodically was all that was needed to connect the dots. Having each server environment PULL the latest version gives a bit more flexibility if you want many test environments. (However, if you’re doing automated PUSH deployment, it’s probably just as practical for you).
  • Same code in test and production: The fact that you can start Jetty inside a plain old JUnit test means that it is ideal for taking your automated tests one step further. However, if you test with Jetty and deploy on a different Application Server, the difference will occasionally trip you. It’s not a big deal. You have to test in the server environment anyway. But why not eliminate the extra source of pain if you can?
  • Licenses: Sure, you can afford to pay a few million $ for an application server. You probably don’t have any better use for that money, anyway, right? However, if you have to pay licenses for each test-server in addition, it will probably mean that you will test less. We don’t want that.
  • Operations: In my experience, operations people don’t like to mess around with the internals of an Application Server. An executable jar file plus a script that can be run with [start|status|stop] may be a much better match.

The missing bits

Taking control of the application server takes away a lot of complex technology. This simplifies and makes a lot of stuff cheaper. It also puts you back in control of the environment. However, it forces you to think about some things that might’ve been solved for you before:

  • Monitoring: The first step of monitoring is simple: Just make sure you write to a log file that is being monitored by your operations department. The second step requires some work: Create a servlet (or a Jetty Handler) that a monitoring tool can ping to check that everything is okay. Taking control of this means that you can improve it: Check if your data sources can connect, if your file share is visible, if that service answers. Maybe add application-calibrated load reporting. Beyond that, Jetty has good JMX support, but I’ve never needed it myself.
  • Load balancing: My setup supports no load balancing or failover out of the box. However, this is normally something that the web server or routers in front of the application server anyway. You might want to look into Jetty’s options for session affinity, if you need that.
  • Security: Jetty supports JAAS, of course. Also: In all the environments I’ve been working with (CA SiteMinder, Sun OpenSSO, Oracle SSO), the SSO server sends the user name of the currently logged in user as an HTTP header. You can get far by just using that.
  • Consistency: If you deploy more than one application as an embedded application server, the file structure used by an application (if any) should be standardized. As should the commands to start and stop the application. And the location of logs. Beyond that, reuse what you like, recreate what you don’t.

Taking control of your destiny

Using an embedded application server means using the application server as a library instead of a framework. It means taking control of your “main” method. There’s a surprisingly small number of things you need to work out yourself. In exchange, you get the control to do many things that are impossible with a big-A Application Server.

Reference: http://www.javaworld.com/community/

Tagged : / / / / / / / / / / / / / / /

How to Use SVN Tasks with ANT ?

svn-tasks-with-ant

This post is about using ANT to perform some of the most common source-control related tasks such as export, tagging, and branching. I am using ANT version 1.7.0 and SVN Ant version 1.1-rc3, bound against Subversion 1.4.0.

The related software can be downloaded here:
1.    SVN Ant = http://subclipse.tigris.org/svnant.html
2.    ANT = http://ant.apache.org/
I shall start with build.properties, which lists a few key/value pairs used in our SVN Ant task build file, referred as svn-tasks.xml:

Content of build.properties:
####START of SVN Properties ####
svn.repository.url=http://xyz.com/repos/somereponame
svn.project.base.path=someprojectname
svn.username=user name to access repo
svn.password=password to access repo
#This shall be name of the tag,
#This property should always be updated before build starts
#This property shall be used to export
tag.name=SOME_TAG_NAME_12222008
#This shall be name of new branch,
#this property should be used only when new branch is to be created
new.branch.name=NEW_BRANCH_12222008
####END of SVN Properties ####
Content of svn-tasks.xml:
<property file=”build.properties”></property>

<!– SVN and SVN-ANT Tasks properties –>
<property name=”svn.repository.url” value=”${svn.repository.url}”/>
<property name=”svn.project.base.path” value=”${svn.project.base.path}” />
<property name=”svn.base.url” value=”${svn.repository.url}/${svn.project.base.path}”/>
<property name=”svnant.lib.dir” location=”svn-ant-lib”/>
<property name=”svnant.javahl” value=”false” />
<property name=”svnant.svnkit” value=”true” />
<!– SVN and SVN-ANT Tasks properties –>

<!– *************************************************************** –>
<!–   Set-Up of SVN-ANT classpath                                   –>
<!– *************************************************************** –>
<path id=”svnant.classpath”>
<fileset dir=”${svnant.lib.dir}”>
<include name=”**/*.jar” />
</fileset>
</path>

<!– *************************************************************** –>
<!–   Loading of SVN task                                           –>
<!– *************************************************************** –>
<typedef resource=”org/tigris/subversion/svnant/svnantlib.xml” classpathref=”svnant.classpath” />

<!– *************************************************************** –>
<!– tool-availability: Determine if SVN-ANT is available.           –>
<!– *************************************************************** –>
<target name=”tool-availability”>
<available resource=”org/tigris/subversion/svnant/svnantlib.xml”
classpathref=”svnant.classpath”
property=”available.svnant”
/>
<echo message=”SVN-ANT is available = ${available.svnant}”/>
</target>

<!– **************************************************************** –>
<!– does-svnant-exist: depends on tool-availablility and     –>
<!–                    displays error message                                   –>
<!– ***************************************************************** –>
<target name=”does-svnant-exist” depends=”tool-availability”>
<fail unless=”available.svnant”>
SVN-ANT is not available, cannot perform tagging or checkout/export svn ant task.
</fail>
</target>

<!– ****************************************************************** –>
<!– svntag: performs tagging using properties from                              –>
<!–         build.properties and uses SVNANT tasks                              –>
<!– ******************************************************************* –>
<target name=”svntag” description=”tags individual project using svnant task”>
<property name=”svn.tag.message” value=”Tagging Project ${project.name} with tag name ${tag.name} from trunk “/>
<property name=”src.url”  value=”${svn.base.url}/${project.name}/trunk/”/>
<property name=”dest.url” value=”${svn.base.url}/${project.name}/tags/${tag.name}”/>

<echo message=”${svn.tag.message}”/>
<echo message=”${src.url}”/>
<echo message=”${dest.url}”/>

<svn javahl=”${svnant.javahl}” svnkit=”${svnant.svnkit}” username=”${svn.username}” password=”${svn.password}”>
<copy srcUrl=”${src.url}” destUrl=”${dest.url}” message=”${svn.tag.message}”/>
</svn>
</target>

<!– ****************************************************************** –>
<!– svnexport: performs export using properties from                            –>
<!–            build.properties and uses SVNANT tasks                           –>
<!– ****************************************************************** –>
<target name=”svnexport” description=”exports individual project using svnant task”>
<property name=”svn.tag.message” value=”Exporting Project ${project.name} with tag name ${tag.name}”/>
<property name=”src.url”  value=”${svn.base.url}/${project.name}/tags/${tag.name}”/>
<property name=”destPath” value=”${dest.path}”/>
<echo message=”${svn.tag.message}”/>
<svn javahl=”${svnant.javahl}” svnkit=”${svnant.svnkit}” username=”${svn.username}” password=”${svn.password}”>
<export srcUrl=”${src.url}” destPath=”${destPath}/${project.name}”/>
</svn>
</target>

<!– ****************************************************************** –>
<!– svnbranch: creates a new branch using properties from                       –>
<!–            build.properties and uses SVNANT tasks                           –>
<!– ****************************************************************** –>
<target name=”svnbranch” description=”creates a new branch for individual project using svnant task”>

<property name=”svn.branch.message” value=”Creating new branch for
Project ${project.name} with new branch name ${new.branch.name} from
trunk”/>
<property name=”src.url”  value=”${svn.base.url}/${project.name}/trunk/”/>
<property name=”dest.url” value=”${svn.base.url}/${project.name}/branches/${new.branch.name}”/>

<echo message=”${svn.branch.message}”/>
<echo message=”${src.url}”/>
<echo message=”${dest.url}”/>

<svn javahl=”${svnant.javahl}” svnkit=”${svnant.svnkit}”
username=”${svn.username}” password=”${svn.password}”>
<copy srcUrl=”${src.url}” destUrl=”${dest.url}” message=”${svn.branch.message}”/>
</svn>
</target>

Link: http://java.dzone.com/articles/how-use-svn-tasks-with-ant

Tagged : / / / / / / / / / / / / / / / / /