……… posted by Davide Pisano

To invoke a method on a session bean, a client does not directly instantiate the bean using the new operator. It use the Dependency Injection (DI) to references the session bean. It is a powerful mechanism used from JavaEE 6 to obtain a resource reference on an object field. It is possible to inject various type of resource, as shown in the next picture.

A DI example Using @EJB annotation could be:

Server Code
@Stateless
public class ItemEJB{
.........
Client Code
.........
@EJB ItemEJB itemEJB
..........

Now Shift attention to the annotation WebServiceRef. It provide to injects a reference to a web service. Having a WSDL, is possible write a java proxy (stub) to invoke a Web Service (WS). There are any tools (wsimport or JDeveloper for example) that provide to generate from a WSDL Java classes and interfaces that make possible the WS execution by a client program. Made interfaces  are called "Service End-Point interface" (SEI) because it is a Java representation of a WS end-point. the SEI is a proxy that provide to a local java call to the remote WS via HTTP.

The Client can get an instance of the proxy through DI using WebServiceRef. Applying this annotation, the container will injects an instance of the WS. As example if MyService is the service proxy produced by the WSDL using one of the tools mentioned above, it is possible to have:

.............
@WebServiceRef
private MyService myService;
...........
MyItem myItem=myService.getMyItemPort();
//use of myItem

If there aren’t containers in our execution environment (it is not a Servlet container, EJB Container or any other that support this annotation), the service class generated by a tool can't be references by the @WebServiceRef annotation but by the new key-word, as in the next example:

.........
MyService myService = new MyService();
MyItem myItem=myService.getMyItemPort();
.........

……… posted by Davide Pisano

……… posted by Davide Pisano

The Servlet version 2.5, introduces new  feature, the most important of which is annotation. The following two sections provide a view on the difference between 2.4 and 2.5 versions and  between 2.5 and 3.0 versions.

……… posted by Davide Pisano

This document is not a Java.io or a Java.nio manual, or a technical document about Java.io and Java.nio use. It only attempts to compare these two packages, highlighting differences and features in the most simple way. Java.nio presents new stream communication aspects and inserts new buffer, file streaming and socket features.

java.io overview

This package is used for system input and output through data streams, and serialization. Streams support many different kinds of data, including simple bytes, primitive data types, localized characters, and objects. A stream is a sequence of data: a program uses an input stream to read data from a source.

A program uses an output stream to write and send data to a destination: 

Programs use byte streams to perform byte input and output. All byte stream classes extends InputStream and OutputStream.

About InputStream and OutputStream

Performing InputStream operations or OutputStream operations means generally having a loop that reads the input stream and writes the output stream one byte at a time. You can use buffered I/O streams for an overhead reduction (overhead generated by each such request often triggers disk access, network activity, or some other operation that is relatively expensive). Buffered input streams read data from a memory area known as a buffer; the native input API is called only when the buffer is empty. Similarly, buffered output streams write data to a buffer, and the native output API is called only when the buffer is full. Those buffered API wrap the unbuffered streams: BufferedInputStream and BufferedOutputStream.

File I/O

The above section focuses on streams, which provide a simple model for reading and writing data. Streams work with a large variety of data sources and destinations, including disk files. However, streams don't support all the operations that are common with disk files.The following links give information on non-stream file I/O. There are two topics:

• File is a class that helps to write platform independent code for examining and manipulating files and directories.

• Random access files support non sequential access to disk file data.

java.net socket

A socket is one endpoint of a two-way communication link between two programs running on the network. Socket classes are used to represent the connection between a client program and a server program. The java.net package provides two classes: Socket and ServerSocket. These implement the client side of the connection and the server side of the connection, respectively.

The client knows the host-name of the machine on which the server is running ,and the port number on which the server is listening. Clients try to connect to the server and if everything goes well, the server accepts the connection. Upon acceptance, the server gets a new socket bound to the same local port and also has its remote endpoint set to the address and port of the client. It needs a new socket so that it can continue to listen to the original socket for connection requests while tending to the needs of the connected client.

The server waits for a client connection in blocking mode: serverSocket.accept() is a blocking instruction, the server waits for a connection and no other operation can be executed by the thread which runs the server. Because of this, the server can work in multitasking only by implementing a multi-thread server: having to create a thread for every new socket created by the server.

NIO API

The I/O performance, often, is a modern application critical aspect. Operative Systems (OS) continuously improve the I/O performance. JVM provides a uniform operating environment that helps the Java programmer in most of the differences between operating-system environments. This makes it faster and easier to write, but the OS feature becomes hidden. To increase IO performance you could write a specific code to access the OS feature directly, but this isn’t the best solution - your code could be OS dependent. Java.nio provides new equipment to address this problem. It provides high-performance I/O features to perform operations on commonly available commercial operating systems today.

The NIO packages of JDK 1.4 introduce a new set of abstractions for doing I/O.

java.nio overview

Java.nio is the new package that implements the New I/O APIs for the Java Platform. The NIO APIs include the following features:

• Buffers for data of primitive types

• Character-set encoders and decoders

• A pattern-matching facility based on Perl-style regular expressions

• Channels, a new primitive I/O abstraction

• A file interface that supports locks and memory mapping

• A multiplexed, non-blocking I/O facility for writing scalable servers

At the sun site is it possible to find exhaustive technical documentation about java.nio. Now I’ll explain some of nio's aspects to show the difference betwen the old library java.io. and java.nio. Be advised, java.nio is not a java.io substitute, rather it is a java.io ‘expansion’. Nio's birth has caused a revision of Io's class and interface (look at this link).

One of the most important aspects of NIO is the ability to operate in non-blocking mode, denied to the traditional java I/O library. But what is non-blocking mode?

Non blocking mode

The bytes of an I/O stream must be accessed sequentially. Devices, printer ports, and network connections are common examples of streams.

Streams are generally, but not necessarily, slower than block devices, and are often the source of intermittent input. Most operating systems allow streams to be placed into non-blocking mode, which permits a process to check if input is available on the stream, without getting stuck if none is available at a given moment. Such a capability allows a process to handle input as it arrives but perform other functions while the input stream is idle. The operating system can be told to watch a collection of streams and indicate which of those streams are ready. This ability permits a process to multiplex many active streams using common code and a single thread by leveraging the readiness information returned by the operating system. This is widely used in network servers to handle large numbers of network connections.

Buffers

Starting from the simplest and building up to the most complex, the first improvement to mention is the set of Buffer classes found in the java.nio package. These buffers provide a mechanism to store a set of primitive data elements in an in-memory container. A Buffer object is a container for a fixed amount of data, a container where data can be read and written.

All buffers are readable, but not all are writable. Each buffer class implements isReadOnly() to indicate whether it will allow the buffer content to be modified.

Channels

Buffers work with channels. Channels are portals through which I/O transfers take place, and buffers are the sources or targets of those data transfers. Data you want to send is placed in a buffer, which is passed to a channel; otherwise, a channel deposits data in a buffer you provide.

A Channel is like a tube that transports data efficiently between byte buffers and the entity on the other end of the channel. Channels are gateways through which the native I/O services of the operating system can be accessed with a minimum of overhead, and buffers are the internal endpoints used by channels to send and receive data.

Channels can operate in blocking or non-blocking modes. A channel in non-blocking mode never puts the invoking thread to sleep. The requested operation either completes immediately or returns a result indicating that nothing was done. Only stream-orientated channels, such as sockets can be placed in nonblocking mode. In the java.nio channel family there are FileChannel, ServerSocketChannel and SocketChannel; these are specific channels created for file and socket management.

FileChannel

FileChannels are read/write channels, they are always blocking and cannot be placed into nonblocking mode. The nonblocking paradigm of stream-oriented I/O doesn't make as much sense for file-oriented operations because of the fundamentally different nature of file I/O.

FileChannel objects cannot be created directly. A FileChannel instance can be obtained only by calling getChannel() on an open file object (RandomAccessFile, FileInputStream, or FileOutputStream). GetChannel() method returns a FileChannel object connected to the same file, with the same access permissions as the file object. FileChannel objects are thread-safe. Multiple threads can concurrently call methods on the same instance without causing any problems, but not all operations are multi-thread. Operations that affect the channel's position or the file size are single-threaded.

Using FileChannel, operations like file copy become a channel to channel trasfer (transferTo() and transferFrom())and read/write operations become easy using buffers.

SocketChannel

SocketChannel is different to FileChannel: The new socket channels can operate in nonblocking mode and are selectable. It's no longer necessary to dedicate a thread to each socket connection, Using the new NIO classes, one or a few threads can manage hundreds or even thousands of active socket connections with little or no performance loss. It's possible to perform readiness selection of socket channels using a Selector object.

There are three socket channel type: SocketChannel, ServerSocketChannel, and DatagramChannel; SocketChannel and DatagramChannel are able to read and write, ServerSocketChannel listens for incoming connects and creates new SocketChannel objects. All the socket channels create a peer socket object when they are instantiated (java.net sockets). The peer socket can be obtained from a channel by invoking its socket() method. While every socket channel (in java.nio.channels) has an associated java.net socket object, not all sockets have an associated channel. If you create a Socket object in the traditional way, by instantiating it directly, it will not have an associated SocketChannel, and its getChannel() method will always return null.

Socket channels can operate in nonblocking mode. The blocking nature of traditional Java sockets has traditionally been one of the most significant limitations to Java application scalability. Non-blocking I/O is the basis upon which many sophisticated, high-performance applications are built. Setting or resetting a channel's blocking mode is easy. Simply call configureBlocking().

Nonblocking sockets are usually thought of for server-side use because they make it easier to manage many sockets simultaneously.

Selector

Selectors provide the ability to have a channel readiness selection, which enables multiplexed I/O. To understand selector feature, I can explain selector advantage using the following example.

Imagine you are in a train station (non-selector), and there are three platforms (channels), and on each platform a train arrives (buffer). On each platform there is a controller for each arrived train (worker thread). That is non-selector.  Now imagine selector.  There are three platforms (channel), on each platform arrives a train (buffer), and each platform has an indicator (a bell for example) that says “Train arrived” (selection key). In this instance there is only one controller for all three platforms.  He looks at the indicator (selector.select()) to find out if a train has arrived and goes to meet that train.

It's simple to understand the advantages of using selector: with a single thread you can obtain a multitasking application. As well as this, you can obtain more advantages using non-blocking selector! Imagine that the train controller looks at the indicator: he can wait for a new train and not do any other thing (blocking mode using selector.select()). But he can instead control tickets, for example, while waiting for a new train (non-blocking mode using selector.selectNow()).  In this way selector returns null and continue to execute code.

IO vs. NIO

NIO construction makes I/O faster than traditional I/O. In a program where the I/O operations constitute a significant amount of the processing, expect to see some difference. For example if an application has to copy files or transfer bytes using sockets, using Nio is possible to obtain a faster performance because it is closer to the OS than the I/O API. Increasing the byte size, the difference becomes  more appreciable. Nio also provides other features not in io API, for streaming operations. However, it is not possible to substitute IO with NIO because NIO API adds functionalities to the java.io. NIO extends the native IO API introducing new possibilities for the developer to manipulate stream data in a powerful way.

References

• JDK 6 Documentation

• “JAVA NIO” - Ron Hitchens - Publisher: O'Reilly

……… posted by Davide Pisano

Download BookmarkPortletLocator.war

Download  BookmarkPortletLocator.pdf

Summary

This WLS JEE Shared Library has been developed in the context of   a customer portal engagement that use WebLogic Portal 10.x (WLP).

Basically we needed a solution to address the recurring problem of plumbing into content html properties some content portal hyperlinks,

• As plain standard http urls, not as server side scriptlets / custom tags;
• Shortened, simplified and portable but yet interpretable by (any) wlp portal instance ‘s navigation context (more on this later);
• The map of such friendly portal urls had also to be exposed to external clients ;

We than implemented a portal url pattern based on generic portlet instances’ bookmarks, instead of on pageLabels: any portlet instance (besides of its parent netuix control) can be administratively labelled via a specific portlet preference, and from that moment on, reachable via a simplified, shortened http url:

http://host:port/<portalWebAppName>/portletlocator/<bookmark_value>

Secondly, more project-scoped, we had also to get an easy way to profile 3.rd party CMS items, when no VCR ‘s SPI were at disposal (in our case we dealt with Interwoven’s TeamSite, still lacking of a fully fledged VCR connector implementation: the only choice was bulk loading), using entities acknowledged by wlp’s UserInteraction API and Tools: those values had to be exposed from portal, retrieved and included in IW forms and then resubmitted to portal, as content item’s metadata.

Disclaimer

This solution has not been –yet- tested in a production environment.

We did some internal performance tests using jrockit ‘s MC tools (basically to get an idea of latency gain in custom cache usage) that showed reassuring results (the overhead of url computing / decoding is in terms of milliseconds…….)

We lend to consider the solution – at this stage –more likely to be wlp code hacking than a real world solution, but yet hope that the underlying idea can be leveraged to develop a similar feature in future wlp releases (we do need it…..)

Following, see comparative results among tests with disabled / enabled url resolution caches

Objectives

In our solution, those urls should also can carry / support a (unpredictable) number of further additional parameters (as querystring params), eventually parsed by the portlet instance’s jsp, to further parameterize –on user request basis - the behaviour of the target jsp portlet’s algorithms (more on this hint on next sections): in our case we needed to customize cm query logic with some external CMS item’s properties.

Another requisite we had to address (which is somehow out of scope for the Locator itself, but still useful set of methods) was also to define and expose (towards 3.rd party CMS), some WLP personalization entities used by WLP Framework and/or WLP UserInteraction personalization engines (i.e. we decided respectively to use streaming Portals / Desktops name-paths, or UserSegments’ rulesets names), so that personalization reasoning logic externally defined could work inside WLP User Interaction engines, even in absence of any VCR SPI implementation.

As said, we than ought to design –on Locator- some logic to

• Intercept, parse and interpret back the friendly, shortened urls, and redirect user to the right portal’s page currently[1] embedding the specific portlet instance, and to forward it also any further CM-specific additional parameters eventually found in friendly url’s querystring.

• Use portals’ p13n or PortalFrameworks API to apply any further personalization / interaction logic to the imported (=bulk loaded…..) CM items.

Last but not least, the solution should grant

• Portability (i.e. moving the target portlet instance to a new portal definition, or promoting it to a different portal instance should not break the semantics and related interpretation of the friendly urls since they had previously loaded and stored into CMS provider…..), considered that no assumption should be done on any sync capabilities between both CM’s metadata repositories (WLP dbms repository and the external one): i.e. the friendly urls should work also when changing portal web context url, or book/pages/portlet instance graph from original.)

• Simplicity: a solution really ready to plug-and-use (both dummy proof but at same time usable without a master degree in wlp / wls): it’s not a “convention over configuration” approach, just we try not to waste time on understanding the syntax of the nth custom xml based configuration file. ;-)

[1] The frendlyUrl-to-pageUrl resolution must be dynamic and based on a indirection entity (bookmark) not on portlet instance id, because portlet instance could reasonably get moved among different pages/desktops/portals in the interval the information is exposed and the item is bulkloaded back to portal…..

Architecture and Components

As said, the Locator consists in a WebLogic JEE Shared Library (PortletLocator.war)

As you link this library, you will find basically three kinds of components:

• 2 web services (….yes, Nino was able to include web services in a web library, can you believe it?)
  • PortalStructureService and UserSegmentService

The interfaces that export wlp-related information towards external clients

• 1 ServletFilter
  • The object that parse and interpret portlet instance’s “friendly” url

• 1 Custom Control:
  • ExposureCoordinatorControl (we warmly hope that Beehive will survive next release of PortletLocator……) , which is the delegator of webservices’s methods, and also a useful interface to some specific computation logic eventually needed from wlp webapp
  • i.e. it can answer questions like: “which usersegment list is current user in?” or “which streaming portal path am currently in?”, etc

All the further supporting / helper / cache logic is packaged in a .jar in the WEB-INF/lib

Installation

Just proceed as a normal shared lib:

1) install the web library in your wlp server / cluster

1) then, add the standard library reference tags in weblogic.xml of your portal web app:

<wls:library-ref>

<wls:library-name>BookmarkPortletLocator</wls:library-name>

<wls:specification-version>1.0</wls:specification-version>

<wls:implementation-version>1.0</wls:implementation-version>

<wls:exact-match>false</wls:exact-match>

</wls:library-ref>

(or use a Deployment Plan)

3) Congratulations! You’re done.

Of course, in a DEV environment, you can include it in the WLS JEE Library list:

Configuration

The library has a complete default configuration: if you don’t have special requirements, it’s all there. You can skip to Usage section.

If you really have to, you can still configure a bunch of parameters (read Usage section to understand the underlying semantics in there; for now just pick up the list):

We didn’t use any new, nth xml configuration file: to override the default configuration you just work on

1. web.xml (context-params)
   1. exposure-scheme
      • this optional parameter is used to set the scheme used to generate the pageurl that the Locator computes before a portal redirect : i.e. https://www.domain.com/myPortalWebApp/appmanager......
      • accepted values: http | https
   2. exposure-host
      • this optional parameter is used to set the hostname part of the pageurl that the Locator generates before a portal redirect : i.e. https://www.domain.com//myPortalWebApp/appmanager......
      • accepted values: an ip address or a hostname
      • if this param is not set, the Locator retrieve it from:
        • wls frontend cluster value, OR
        • wls frontend server host value, OR
        • value returned from getServerName method invoked by Locator filter on current http request
   3. exposure-port
      • this optional parameter is used to set the port part of the pageUrl generated by Locator: needs to be set if specified “exposure-host”
      • accepted values: any valid tcp port
   4. exposure-log-enabled
      • this optional parameter is used to set the log of the Locator framework
      • log file defaults to PortletLocator.log and is placed on domain root folder (this behaviour can be overridden by a proper log configuration on weblogic.xml of referencing portal app –see below).
      • accepted values: true (default) OR false
   5. exposure-production-mode
      • accepted values: true OR false
      • this param defaults to domain’s current runtime mode (production vs. development) being retrieved straight from domain configuration itself.
      • IF explicitly set to false in a production environment, enables DEBUG trace level on log file (viceversa on prod configuration, debug level is disabled for performance reason
      • exposure-log-enabled param needs to be enabled and set to true.
   6. exposure-portal-servlet-mapping
      • anybody should have changed the /appmanager url pattern of wlp portal servlet, this parameter allows to configure PortletLocator accordingly about the new PortalServlet ‘s servlet url mapping.
      • defaults to /appmanager
      • accepts any string value
   7. exposure-portlet-preference-name
      • the preference name of the portlet preference that – on a portlet instance - identify the bookmark itself
      • defaults to: “bookmark”
      • accepted values: any string
   8. exposure-cache-enabled
      • accepted values: true (default) OR false
      • this parameter enables Locator’s url resolution caches: EXPOSURE_CACHE and EXPOSURE_CACHE_URL, administerable from Portal Admin Console

   9. exposure-redirect-request-enabled

      • accepted values: true (default) OR false

      • this parameter enables Locator to redirect  users to target portlet  via a http 302  status code send-redirect (when landing on target portlet, the browser address url is the portal one); choosing false enables servlet container internal forwarding mechanism (when landing on target portlet, the browser address url is the locator one)
   10. you can also modify url pattern value of Locator’s servlet filter
       • default: “portletlocator”
       • this values can be overridden by adding in web.xml of portalWebApp these lines:
       • i.e. . http://www.domain.com/runtimeservices/simple1

    <filter>

       <filter-name>ContentLocatorFilter</filter-name>

       <filter-class>it.javac.bea.portal.exposure.filter.ContentLocatorFilter</filter-class>

   </filter>

   <filter-mapping>

       <filter-name>ContentLocatorFilter</filter-name>

       <url-pattern>/runtimeservices/*</url-pattern>

       <dispatcher>FORWARD</dispatcher>

       <dispatcher>REQUEST</dispatcher>

      <dispatcher>INCLUDE</dispatcher>

   </filter-mapping>

       2  weblogic.xml

  <wls:logging>

      <wls:log-filename>PortletLocator.log</wls:log-filename>

      <wls:logging-enabled>true</wls:logging-enabled>

      <wls:file-count>3</wls:file-count>

      <wls:file-size-limit>5000</wls:file-size-limit>

      <wls:rotate-log-on-startup>true</wls:rotate-log-on-startup>

      <wls:log-file-rotation-dir>logs</wls:log-file-rotation-dir>

  </wls:logging>

Defaults, the PortletLocator creates 2 new portal caches with 1h TTL:

• EXPOSURE_CACHE with max entries 100
• EXPOSURE_CACHE_URL with max Entries 500

Usage

Let’s distinguish Locator’s usage into 2 different context / use cases:

• Implementation of portal friendly url,
• External content item’s personalization

Friendly urls implementation

Phase 1 : create friendly urls

(WLP Portal side; role: PortalAdministrator; tool: PortalAdminTool)

1. Configure your 1-n streaming portal(s), each with related desktops / books / etc
2. For each portlet instance (among those eligible as friendly url” ‘s target, i.e. to CM display views),
   • Add a portlet instance.
   • Add a portlet preference named “bookmark” (this is default but can be customized), with a unique value [1]
   • i.e. : simple1
   • Add a preference description
   • i.e.: “upper left portlet, 3^rd column, new articles annoncements….” Etc

[1] By now no control is made on bookmark’s preference value uniqueness: we didn’t find an efficient solution to automate this control on portal lifecycle stages (i.e. web app deployment time, new preference insertion, etc)

From this moment on, with PortletLocator deployed and configured, you can reach this portlet instance by composing this url on a browser:

http://<my_portal_instance>:<myport>/<myWebContenxtPath>/portletlocator/simple1

When you hit a non existing bookmark, the filter send back a Http Error Code 436 (to let you customize error handling with a friendly page / error handler)

Phase 2 : exposition of portlet instances friendly url map to third party consumer

Navigate to Web Service ‘s PortalStructureService WSDL and test operation availablePortletsBookmark: an invocation returns the full map of bookmarked portlets: a list of following key/values

• bookmark’s preference description
• bookmark’s preference values associated with each bookmarked portlet

following an example of returned values:

Phase 3: inclusion of bookmark map into CM contribution tool

This key/value list can then be easily embedded in external CM contribution tool (in our case, into TeamSite’s forms) in the form of a combo box: the options key being the bookmark value, while the options value being the portlet instance description.

The redactor, when he needs to plumb an hyperlink on an html body of a cm item, can than select a bookmark’s value by selecting his description.

Note that any duplicated entry of bookmark_value / portlet instance description has to be handled manually with a fix in wlp’s portal admin tool.

Just store this picked value (the bookmark’s preference value) in a cm specific item property / metadata (i.e. WLP_BOOKMARK)

Phase 4: hyperlink compilation

(CM side; role: CM developer)

At export time (i.e when preparing content item for wlp’s bulkloading) in our solution, Interwoven developers just parsed html content for any CM proprietary hyperlinks;

If present, they queried the target’s item WLP_BOOKMARK property with that value, they invoked again Locator’s PortalStructureService , just a different operation: getContextUrlFromBookmark[1]:

• this operation returns the (relative) context path of a given bookmark (es. /myportalWeb/portletlocator/p1).

In this way the bookmark definition itself is decoupled from current portalweb-scoped configuration, that can differ among different environments, deployments, evolutions, etc), use the result to compose href attribute of resulting anchor tag inside cm item html property.

At this stage the CM developer can choose to add further querystring parameters(as the result of additional target cm metadata enquiry, i.e. ITEM_ID, Locale, WLP_PortalPath, WLP_UserSegments, more on that following)

The resulting url could be:

/myportalWeb/portletlocator/p1?item_id=2323123&Locale=it&wlp_portal_path=pmi

[1] In next release the bookmark-to-webcontext url resolution could be moved inside the portal itself, using some Ajax feature at click time

Phase 5: url parsing (WLP side)

After bulkloaded the item(s), and CM display temaplates / jsp implemented and deployed, any /portletlocator links get intercepted by PortletLocator’s ServletFilter;

This filter picks up the bookmark value in servletpath and compute the actual and current pageUrl on which target portlet instance is – currently – instantiated in.

The user is redirected or forwarded (based on exposure-redirect-request-enabled configuration parameter) to portal’s page url .

Should any additional querystring parameters be present in url, the filter copies them in (Outer)Request scope (or Sessione scope, if configured), so that target portlet can take advantage of them to further customize the default behaviour of i.e. content display logic: for instance you can use item_id request parameter to select a specific content item (given you provided a corresponding cm property / metadata and that this id is really unique across the CM Repository).

Content items personalization

Phase 1 : define and implement your personalization entities

(WLP side)

First you had to identify which portal entities you will use to as personalization discriminating data useful to profile your cm item: you can decide to “tag” target user segments using both

• wlp user segments, or
• wlp streaming portal path(s)

Locator expose those two list in two different web services:

1. in PortalStructureService
   • availablePortalPath : returns a key/value list of currently configured streaming portals’ path/name
   • availableDesktopPath : given an (optional) portal path, returns a key/value list of currently configured desktops’ path/name
2. in UserSegmentService
   • availableSegments : returns the list of currently configured user segments

Phase 2: inclusion of portal path list / user segments list into CM contribution tool

You can follow same guidelines to include to external CM tool those lists: the redactor would than just pickup the current usersegment / current portal that specific item is targeted to, and store it this value in a specific cm item property / metadata (i.e. WLP_USERSEGMENTS, or WLP_PORTAL_PATH).

Phase 3: cm personalization property evaluation

(WLP side)

On wlp side, when implementing cm display templates or jsps, you can select the cm item to show by comparing:

• current item / node ‘s personalization property (i.e. WLP_USERSEGMENTS, or WLP_PORTAL_PATH)
• with current user ‘s user segment or current portal path

The latter being a portlet instance’s preference while the former the result of a dynamic evaluation leveraging Locator’s custom control API:

ExposureCoordinatorControl.

String[] segmentOfUserFromRequest(HttpServletRequest request)

• Given an instance of HttpRequest, returns the list of usersegments this current user (both anonymous or logged) is in.
• NB: this latter method makes no use of any cache. Use it with awareness…..

Nino Guarnacci & Gabriele Folchi

nino.guarnacci@oracle.com gabriele.folchi@oracle.com