Glassfish3+ & ADF 11g: Developing ADF apps on Glassfish using Jdeveloper 11g

There was no opportunity before to develop an Oracle ADF (Application Development Framework) applications on any open source application server such as Tomcat, or Glassfish, while Glassfish is the Oracle reference implementation now for JEE specifications. The only way is to develop on Oracle Weblogic application server. Even using oracle enterprise pack (OEPE) for development on eclipse IDE.

Nowadays oracle releases the ADF essentials.With the new Oracle ADF Essentials which is offering you now the ability to deploy applications that leverage Oracle ADF on the open source Glassfish 3.1 server.

At Oracle ADF Essentials home page you can check what are supported in comparison with the full ADF library, and also there are a lot of tutorials for learning the framework.

Now will get an introduction on how to setup the development environment, then we will develop a small application using Jdeveloper 11g and deploy it on the Glassfish 3.1.2.2 application server.

• Setting up the environment:
  
  
  1. Download the following if you don’t have any of them:ADF essential library (11.1.2.3), JDeveloper 11g (11.1.2.3.0) and Glassfish 3.1.2.2.
  2. Install Jdeveloper 11g and Glassfish server and check that everything is up and running.
  3. Once ADF essential library downloaded, we need to unzip it inside the lib folder of Glassfish domain1 (or any domain you have created) this will get you an adf-essentials.zip file.
     
     
  4. To install ADF essentials:
     
     
     1. Copy the adf-essentials.zip file into the lib(on a default windows install this would be: "C:\glassfish3\glassfish\domains\domain1\lib\ext") folder of your glassfish domain.
     2. In lib folder open command window and issue a "unzip -j adf_essentials.zip"
        
        
        
        
        
        
     3. Note: you should use "-j" option with unzip (JDK program) command or you will ends up with folders not the jar files, try it and you will see.
     
     
  5. After successful extraction of the ADF libraries to the directory. Now you can start the Glassfish server (you can start your domain by the following command inside "bin" folder of your "domain" "asadmin start-domain domain1" from command line console, wait for domain to start then you should ends up with message "Command start-domain executed successfully.").
     
     
  6. We need to configure the glassfish to work with application of ADF type:
     
     1. Invoke the admin console of glassfish (http://localhost:4848) and log into your admin account.
     2. Go to Configurations->Server-config->JVM Settings and choose the JVM Options tab
     3. Add the following entries:
        
        1. -XX:MaxPermSize=512m (note this entry should already exist so just make sure it has a big enough value)
        2. -Doracle.mds.cache=simple
  7. There is a new extension ("Glassfish 1.3" as time of writing) that allows you to start and stop an external GlassFish instance, as well as start it in debug mode (which will allow JDeveloper to remotely debug your application as it runs on the server. Also a button that will invoke the web admin console of Glassfish.
     
     
  8. After installing Jdeveloper, open it, the extension is available from help->check for updates, or you can download it directly from here, and then use help->check for updates pointing to the local zip file (Thanks Shay Shmeltzer's who developed this extension).
     
     
  9. After the Jdeveloper finished download and the installation of the extension, you should find 4 glassfish buttons in the menu.
     
     
     
     
     
     
  10. Go to Tools -> Preferences -> Glassfish Preferences, here you can configure the glassfish paths and configurations you like.
  
  
• Developing and deploying the ADF application:
  
  
  1. Creating and configuring the application to work with Glassfish:
     
     
     1. In JDeveloper choose File -> new, the New Gallery window will pop up, from right hand menu choose General-> Applications, and then from left hand choose Fusion Web Application.
        
        
        
        
        
        
     2. After successful application creation.
     3. Go into the project properties of your viewController project, under the deployment section click to edit the deployment profile that is defined there.
     4. Go to Platform and choose Glassfish 3.1 from the drop down list. Click ok to go back to your project properties.
     5. Under Java EE Application section in project properties change the Java EE web application name and context to the same value "ADFGF" (for ease of access when deploy the application).
     6. Go to Application -> Application Properties-> Deployment
     7. Go to Platform and choose Glassfish 3.1 from the drop down list. Click ok to go back to your project.
     8. This step will make sure that JDeveloper will automatically add the necessary ADF libraries to the EAR file that is being generated for deployment on Glassfish.
        
        
  2. Developing and Deploying the application:
     
     
     1. Right click on viewController project and choose new.
     2. Under Web Tier -> JSF/Facelets -> Page -> Ok.
     3. File name: TestADFGF.jsf, under the managed bean tab name: testADFGF leave the others with default values. Click ok.
     4. The page will be opened in visual editor.
     5. Drag and drop any components you like as a command button, check box, choose date and choose color component.
     6. We need to create application server connection.
     7. Start the application server from glassfish start icon in the JDeveloper menu.
     8. From Application servers Navigator, right click on application servers -> new. From New Gallery windows choose General-> Connections -> Application Server Connection -> ok.
     9. In the new windows Connection name: Glassfish3122, type: Glassfish 3.1 next.
     10. Provide your application server username and password then next.
     11. Configure your ports and host name, next.
     12. In the final step with glassfish running hit test connection button and the four testing steps should succeed.
         
         
         
     13. Go to your Application->Deploy and deploy either to an EAR file or directly to a Glassfish server connection that you created.
     14. After successful deployment you should get the following message:
         
         
         
     15. Open you browser and type the following URL (http://localhost:9090/ADFGF/faces/TestADFGF.jsf), you should see the following result:
         
         
         
     16. Things should just work, but if they don't then look up the server.log in the log directory and check out what error is in there.
         
         

Congratulations, you did it, now you are have the capabilities to develop any JSF/ADF applications from JDeveloper and host it on Glassfish 3.1.2.2.

Architecture: Modeling & Designing Software Projects Architecture

When I model and design the architecture of software project, first thing I consider is what is the software project type?

My experience in this field of projects architecture has taught me that most applications fails into seven software types, each type has its own technology's, communication patterns, architectural patterns and design steps.

The software categories are:

1. Object oriented Software:

The object-oriented design uses the concepts of information hiding, classes, and inheritance. This results in the design of a sequential object-oriented software architecture, which would be implemented as a sequential program with one thread of control.

2. Client / Server Software.

In these systems, a client is a requester of services and a server is a provider of services. Typical servers are file servers, database servers, and line printer servers. Client/server architectures are based on client/service architectural patterns, the simplest of which consists of one service and multiple clients. This pattern has several variations, which will be described next. In addition, certain decisions need to be considered about the design of client/server architectures, such as whether the server should be designed as a sequential or concurrent subsystem, what architectural structure patterns to use for the design of the client/server architecture, and what architectural communication patterns to use for interaction between the clients and the services.

Also differentiates between a server and a service. A server is a hardware/ software system that provides one or more services for multiple clients. A service in a client/server system is an application software component that fulfills the needs of multiple clients. Because services execute on servers, there is sometimes confusion between the two terms, and the two terms are sometimes used interchangeably. Sometimes, a server will support just one service or perhaps more than one; on the other hand, a large service might span more than one server node. In client/server systems, the service executes on a fixed server node(s) and the client has a fixed connection to the server.

3. Service-Oriented Architecture.

SOA is a distributed software architecture that consists of multiple autonomous services. The services are distributed such that they can execute on different nodes with different service providers. With a SOA, the goal is to develop software applications that are composed of distributed services, such that individual services can execute on different platforms and be implemented in different languages. Standard protocols are provided to allow services to communicate with each other and to exchange information. In order to allow applications to discover and communicate with services, each service has a service description; the service description defines the name of the service, the location of the service, and its data exchange requirements.

A service provider supports services used by multiple clients. Usually, a client will sign up for a service provided by a service provider, such as an Internet, email, or Voice over Internet Protocol (VoIP) service. Unlike client/server architectures, in which a client communicates with a specific service provided on a fixed server configuration, this chapter describes SOAs, which build on the concept of loosely coupled services that can be discovered and linked to by clients (also referred to as service consumers or service requesters) with the assistance of service brokers. This document describes how to design SOAs, how to design services, and how to reuse services.

4. Distributed Component-Based Software.

In the design of software architectures for a distributed component-based software design; the component-based software architecture for the distributed application is developed. The software application is structured into components, and the interfaces between the components are defined. To assist with this process, guidelines are provided for determining the components. Components are designed to be configurable so that each component instance can be deployed to a different node in a geographically distributed environment.

Components are initially designed using the subsystem structuring criteria. Additional component configuration criteria are used to ensure that components are indeed configurable – in other words, that they can be effectively deployed to distributed physical nodes in a distributed environment.

5. Concurrent Real-Time Software.

The real-time software is a concurrent architecture usually, having to deal with multiple streams of input events. They are typically state-dependent, with either centralized or decentralized control.

Real-time software architectures are concurrent architectures that usually have to deal with multiple streams of input events. They are typically state-dependent, with either centralized or decentralized control. Thus, the design of finite state machines, state-dependent interaction modeling, and the control patterns, are very important in the design of real-time software architectures.

6. Software Product Line.

It is architectures for families of products that need to capture both the commonality and variability in the family.

A software product line (SPL) consists of a family of software systems that have some common functionality and some variable. Software product line engineering involves developing the requirements, architecture, and component implementations for a family of systems, from which products (family members) are derived and configured.

The problems of developing individual software systems are scaled upwards when developing SPLs because of the increased complexity due to variability management.

As with single systems, a better understanding of a SPL can be obtained by considering the multiple views, such as requirements models, static models, and dynamic models of the product line. A graphical modeling language such as UML helps in developing, understanding, and communicating the different views. A key view in the multiple views of a SPL is the feature modeling view. The feature model is crucial for managing variability and product derivation because it describes the product line requirements in terms of commonality and variability, and defines the product line dependencies. Furthermore, it is desirable to have a development approach that promotes software evolution, such that original development and subsequent maintenance are both treated using feature-driven evolution.

7. Framework Software.

A software framework is an abstraction in which software providing generic functionality can be selectively changed by user code, thus providing application specific software. It is a collection of software libraries providing a defined application programming interface (API). It is a universal, reusable software platform used to develop applications, products and solutions.

Software Frameworks include support programs, compilers, code libraries, an application programming interface (API) and tool sets that bring together all the different components to enable development of a project or solution.

Frameworks contain key distinguishing features that separate them from normal libraries:

7.1. Inversion of control - In a framework, unlike in libraries or normal user applications, the overall program's flow of control is not dictated by the caller, but by the framework.

7.2. Default behavior - A framework has a default behavior. This default behavior must actually be some useful behavior and not a series of no-ops.

7.3. Extensibility - A framework can be extended by the user usually by selective overriding or specialized by user code providing specific functionality.

7.4. Non-modifiable framework code - The framework code, in general, is not allowed to be modified. Users can extend the framework, but not modify its code.

-----------------------------------------------------------------------
Last thing is very important should be considered when architecting any project. It is Non-Functional requirements and should be taken into consideration when designing such software types from the modeling and design stage not when implementing the project.

In my architecture document I called it Software quality attributes.

Software quality attributes:

Refer to the nonfunctional requirements of software, which can have a profound effect on the quality of a software product. Many of these attributes can be addressed and evaluated at the time the software architecture is developed. Software quality attributes include maintainability, modifiability, testability, traceability, scalability, reusability, performance, availability, and security.

Some software quality attributes are also system quality attributes because they need both the hardware and software to achieve high quality. Examples of these quality attributes are performance, availability, and security. Other software quality attributes are purely software in nature because they rely entirely on the quality of the software. Examples of these quality attributes are maintainability, modifiability, testability, and traceability.

Webservice: Part 3- Create, compile and publish WS using JDK only (No App. Server)

In Part 1 i have introduced the web services, and how to create, implement and publish WS then show the resulting WSDL.

After that in Part 2 i have implemented a Java Requester for the Web Service created in part 1.

In this part i will implement a multithreading version of the Endpoint Publisher to accept concurrent requests.

Multithreading the Endpoint Publisher

In the examples so far, the Endpoint publisher has been single-threaded and, therefore, capable of handling only one client request at a time: the published service completes the processing of one request before beginning the processing of another request. If the processing of the current request hangs, then no subsequent request can be processed unless and until the hung request is processed to completion.

In production mode, the Endpoint publisher would need to handle concurrent requests so that several pending requests could be processed at the same time. If the underlying computer system is, for example, a symmetric multiprocessor (SMP), then separate CPUs could process different requests concurrently.

On a single-CPU machine, the concurrency would occur through time sharing; that is, each request would get a share of the available CPU cycles so that several requests would be in some stage of processing at any given time. In Java, concurrency is achieved through multithreading. At issue, then, is how to make the Endpoint publisher multithreaded. The JWS framework supports Endpoint multithreading without forcing the programmer to work with difficult, error-prone constructs such as the synchronized block or the wait and notify method invocations.

An Endpoint object has an Executor property defined with the standard get/set methods. An Executor is an object that executes Runnable tasks; for example, standard Java Thread instances. (The Runnable interface declares only one method whose declaration is public void run().) An Executor object is a nice alternative to Thread instances, as the Executor provides high-level constructs for submitting and managing tasks that are to be executed concurrently.

The first step to making the Endpoint publisher multithreaded is thus to create an Executor class such as the following very basic one:

The class MyThreadPool creates a pool of 10 threads, using a fixed-size queue to store the threads that are created under the hood. If the pooled threads are all in use, then the next task in line must wait until one of the busy threads becomes available.

All of these management details are handled automatically. The MyThreadPool class overrides a few of the available methods to give the flavor.

A MyThreadPool object can be used to make a multithreaded Endpoint publisher. Here is the revised publisher, which now consists of several methods to divide the work:

Once the ThreadPoolWorker has been coded, all that remains is to set the Endpoint publisher's executor property to an instance of the worker class. The details of thread management do not intrude at all into the publisher.

The multithreaded Endpoint publisher is suited for lightweight production, but this publisher is not a service container in the true sense; that is, a software application that readily can deploy many web services at the same port.

A web container such as Tomcat, which is the reference implementation, is better suited to publish multiple web services.

References:
Java Web Services: Up and Running, 1st Edition

Webservice: Part 2- Create, compile and publish WS using JDK only (No App. Server)

In part 1 i gives an introduction to web services,then created, implemented and published a WS, after that show the resulting WSDL.

In this part i will show you how to implement a Java Requester of the Web Service created in part 1.

A Java Requester of the Web Service

Example 1. Java client for the Java web service

The Java client uses the same URL with a query string, but the Java client explicitly creates an XML qualified name, which has the syntax namespace URI:local name.

A URI is a Uniform Resource Identifier and differs from the more common URL in that a URL specifies a location, whereas a URI need not specify a location. In short, a URI need not be a URL. For now, it is enough to underscore that the Java class java.xml.namespace.QName represents an XML-qualified name.

In this example, the namespace URI is provided in the WSDL, and the local name is the SIB class name TimeServerImpl with the word Service appended. The local name occurs in the service section, the last section of the WSDL document.

Once the URL and QName objects have been constructed and the Service.create method has been invoked, the statement of interest:

Executes. Recall that, in the WSDL document, the portType section describes, in the style of an interface, the operations included in the web service. The getPort method returns a reference to a Java object that can invoke the portType operations.

The port object reference is of type eg.com.tm.ws.ts.TimeServer, which is the SEI type. The Java client invokes the two web service methods; and the Java libraries generate and process the SOAP messages exchanged transparently to enable the successful method invocations.

In part 3 i will show you how to implement WS created in part 1 to accept concurrent requests.

Webservice: Part 1- Create, compile and publish WS using JDK only (No App. Server)

This is 3 parts series as the following:

1. Part1: introduction to web services, create, implement and publish WS then show the resulting WSDL.
2. Part2: A Java Requester of the Web Service created in part 1.
3. Part3: Multithreading the Endpoint Publisher version for the same service created in part 1.

What Are Web Services?

Although the term web service has various, imprecise, and evolving meanings, a glance at some features typical of web services will be enough to get us into coding a web service and a client, also known as a consumer or requester. As the name suggests, a web service is a kind of webified application, that is, an application typically delivered over HTTP (Hyper Text Transport Protocol).

A web service is thus a distributed application whose components can be deployed and executed on distinct devices. For instance, a stock-picking web service might consist of several code components, each hosted on a separate business-grade server, and the web service might be consumed on PCs, handhelds, and other devices.

Web services can be divided roughly into two groups, SOAP-based and REST-style. The distinction is not sharp because, as a code example later illustrates, a SOAP-based service delivered over HTTP is a special case of a REST-style service. SOAP originally stood for Simple Object Access Protocol but, by serendipity, now may stand for Service Oriented Architecture (SOA) Protocol.

Deconstructing SOA is nontrivial but one point is indisputable: whatever SOA may be, web services play a central role in the SOA approach to software design and development. (This is written with tongue only partly in cheek. SOAP is officially no longer an acronym, and SOAP and SOA can live apart from one another.)

JEE7: Looking ahead to a new era

Get educated about Java EE 7 JSRs.

With the release of Java EE 7 scheduled for the second half of 2012, projected JSRs are all up and running. The Java EE 7 release, which will reflect the evolving needs of the industry as it moves into the cloud, is date driven: anything not ready will be deferred to Java EE 8.

Here is an update and summary of the key features of different specifications in the Java EE 7 platform.

JEE6: Stress Testing Java EE 6 Applications, how to?

Use stress testing to identify application server configuration problems, potential bottlenecks, synchronization bugs, and memory leaks in Java EE 6 code.

Unit and integration tests are helpful for the identification of business logic bugs, but in the context of Java Platform, Enterprise Edition 6 (Java EE 6), they are meaningless. Both integration and unit tests access your application in a single-threaded way.

After the deployment, however, your code will always be executed concurrently.

Stop Talking, Start Stressing

It is impossible to predict all nontrivial bottlenecks, deadlocks, and potential memory leaks by having theoretical discussions. It is also impossible to find memory leaks with unit and integration tests. Bottlenecks are caused by locks and I/O problems that are hard to identify in a single-threaded scenario. With lots of luck and patience, memory leaks can be identified with an integration test, but they can be far more easily spotted under massive load.

The heavier the load, the greater is the probability of spotting potential concurrency and robustness problems. Cache behavior, the frequency of Java Persistence API (JPA) OptimisticLockException, and the amount of memory needed in production can also be evaluated easily with stress tests.

JEE6: Is war package is the new ear ?

The pragmatic way of modularization and packaging...

It is not only possible to put EJBs and JSR-299 Beans together directly into a WAR - EJBs can be also packaged separately into a JAR. After copying the “ejb-jar” into the [WAR]/WEB-INF/lib folder, the included beans become automatically available to the web app.

No additional configuration or tweaking is required. In the contrary to the the old EAR packaging, all the classes are loaded with the same classloader. There is no difference between packaging the beans in a standalone JAR, or putting the byte code directly into the WEB-INF/classes folder.

You could even sprinkle the beans in as many JARs as you like - the Dependency Injection between them will just work. Because all the JARs inside the WEB-INF/lib are loaded by exactly the same classloader - it just behaves like a single JAR.

The new Java EE 6 WAR-packaging is interesting for the majority of the “business” projects with “weak” requirements regarding the modularization. You can partition your software into dependent pieces, without paying the costs of true JAR-isolation.

The EAR packaging is still interesting for projects with higher modularization requirements - here the EJB-JARs will be loaded with an isolated classloader separately. In the majority of all cases it is just an overhead: it is unlikely, that someone will replace a single EJB-JAR without rebuilding and testing the whole EAR...

from Adam Bien's blog

JDeveloper: Setting up JRebel with JDeveloper 11g

The following provides a quick walkthrough on how to enable JRebel for a JEE web project in the Oracle’s JDeveloper IDE. JDeveloper version 11g was used for creating this tutorial, but other versions are expected to work similarly.


Now you just need a web application and to enable JRebel for it. To do it, two steps are necessary:

1. enabling JRebel in application server’s launch configurations for the current web-app
2. adding the JRebel’s project-specific configuration file (rebel.xml) into your project’s classpath

0. Creating a web project

This is the “step 0″ as probably you’ll want to enable JRebel for a web project you already have. Anyway, for this tutorial we created a demo application with the Create Web Project wizard (right click in Application Navigator,New .. -> General -> Projects -> Web Project).

To demonstrate JRebel working, a servlet and a JSP page were added to the project. While adding a JSP page was a matter of checking the “include JSP page” box during the web project creation, adding a servlet was just as easy by right-clicking on the project name (in Projects navigator) -> New.. ->Web Tier -> Servlets -> HTTP Servlet. We should now have a project structure something like the following:

1. Enabling JRebel in app-server’s launch configuration

First you need to tell the IDE to start the application server (WebLogic by default) with the JRebel’s javaagent. Go through the following steps:

1. Right-click on your project in the Application Navigator, open Project Properties..
2. Open the Run/Debug/Profile tab
3. Open the edit dialog for the chosen run configuration (click Edit..)
4. In the Launch Settings tab, edit the Java Options. Append all the desired configuration options for JRebel. The minimal install string is: -noverify -javaagent:C:\path\to\jrebel\jrebel.jar, where the javaagent path is adjusted according to your local JRebel installation path.

Verification: When you start your application on the application server (by right-clicking on your servlet-file or your JSP-file and hitting Run..) for the first time and observe the server log, you have to see a large JRebel banner near the beginning of the server log. Something like this:

...
starting weblogic with Java version:
Starting WLS with line:
/home/sander/apps/oracle-jdev/jdk160_18/bin/java -client   -Xms256m -Xmx512m ...

#############################################################

 JRebel 4.5.1
 (c) Copyright ZeroTurnaround OU, Estonia, Tartu.

 Over the last 1 days JRebel prevented
 at least 9 redeploys/restarts saving you about 0.4 hours.

 This product is licensed to Mohamed Mahmoud Taman.
 for non-commercial use only.

 The following plugins are disabled at the moment:
 * EclipseLink Plugin (set -Drebel.eclipselink_plugin=true to enable)
Reloads EntityManagerFactory when configuration changes
 * Grails Plugin (set -Drebel.grails_plugin=true to enable)
...
#############################################################

Server startup options can also be modified in the server’s Properties view accessed through the Application Server Navigator, but this doesn’t seem to work. The configuration dialog also includes a warning that these settings are used only when starting the server without any application selected… anyway, somehow the settings are not picked up and the server starts up without JRebel (you know it by seeing no JRebel banner in the beginning).

2. Creating the rebel.xml configuration file

You also need to create a project-specific JRebel configuration file (rebel.xml) to tell JRebel which locations to monitor for the updated versions of class files and other resources. The rebel.xml descriptor needs to end up in your project’s classpath (under WEB-INF/classes).

Probably the quickest is to right-click on Application Sources, pick New.. -> All Items -> File. For further information on rebel.xml configuration file refer to the appropriate documentation; anyway, here’s an example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<application>
    <classpath>
        <dir name="/home/sander/dev/jdeveloper/DemoProject/classes" />
    </classpath>
    <web>
        <link target="">
            <dir name="/home/sander/dev/jdeveloper/DemoProject/public_html" />
        </link>
    </web>
</application>

The two things here are the path to the directory where your IDE compiles the classes and the path to the directory where your IDE constructs the so-called “web root” directory (i.e. a directory that contains mostly the same things as the war-file after extracting). It is not important that the web root directory also contains the WEB-INF/classes and WEB-INF/lib directories, as the classes are picked up from the path in the <classpath>and libraries are not expected to change.

The path to where JDeveloper is building the classes is defined by the Output Directory setting in the Project Properties -> Project Source Paths view; the default value for it is $PROJECT_ROOT/classes. The web root of the web project should also be located directly in the project’s root directory; by default it is$PROJECT_ROOT/public_html.

Run the application on the server to test whether JRebel has been set up properly. In our case, the easiest is to direct our browser to the URL where the auto-generated servlet is just outputting some HTML:

public class Servlet1 extends HttpServlet {
    // ..
    public void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException
    {
        response.setContentType(CONTENT_TYPE);
        PrintWriter out = response.getWriter();
        out.println("<html>");
        out.println("<head><title>Servlet1</title></head>");
        out.println("<body>");
        out.println("<p>The servlet has received a GET. This is the reply.</p>");
        out.println("</body></html>");
        out.close();
    }
}

Obviously, without JRebel’s code reloading, changing anything in this Java code wouldn’t be seen in the browser until we redeploy. Convince yourself that recompiling the edited servlet results in the output also changing in the browser after hitting F5 (if you did configure everything correctly).

Thanks JRebel development and blog for information.

App. Server: Application deployment to a reserved port number

Ensure that you avoid reserved port numbers when deploying your application. Some application servers will fail to prevent you from deploying your application on a reserved server port:

(e.g. 1, 7, 9, 11, 13, 15, 17, 19, 20, 21, 22, 23, 25, 37, 42, 43, 53, 77, 79, 87, 95, 101, 102, 103, 104, 109, 110, 111, 113, 115, 117, 119, 123, 135, 139, 143, 179, 389, 465, 512, 513, 514, 515, 526, 530, 531, 532, 540, 556, 563, 587, 601, 636, 993, 995, 2049, 3659, 4045, 6000, 6665, 6666, 6667, 6668, 6669).

If you use one of these reserved ports, some web browsers may honor it but at least WebKit-based browsers (e.g. Safari and Google Chrome) will not.

You may see some page content but all resources (images and styles) will fail to load.