Spring creates a separate
threads to handle schedulers , but most of J2EE container vendors like
websphere , weblogic ..etc doesn't support the threads created outside of
containers. (These are threads called unmanaged threads)

Following exception was
thrown when we try to lookup the objects directly using
javax.naming.initialContext . (We have JAX-RPC webservices client code
that is generated by RAD using WSDL , which is auto generated code has the
direct initial context lookups)

Exception
Occured

javax.naming.ConfigurationException: A JNDI
operation on a "java:" name cannot be completed because the server
runtime is not able to associate the operation's thread with any J2EE
application component. This condition
can occur when the JNDI client using the "java:" name is not executed
on the thread of a server application request.
Make sure that a J2EE application does not execute JNDI operations on
"java:" names within static code blocks or in threads created by that
J2EE application. Such code does not
necessarily run on the thread of a server application request and therefore is
not supported by JNDI operations on "java:" names. [Root exception is
javax.naming.NameNotFoundException: Name "com/env/url/testrouce"

Explanation
and solution

IBM clearly states
that don't create unmanaged threads (this is true with most of J2EE container
vendors), for the following reasons:

The application server does
not recognize unmanaged threads.

Unmanaged threads do not have
access to Java EE contextual information.

Unmanaged threads can use
resources without being monitored by the application server.

Unmanaged threads can
adversely affect application server functions such as shutting down
gracefully or recovering resources from failure.

An administrator cannot
control the number of unmanaged threads or their use of resources.

<!-- To schedule
job for every one hour then cron will be "0 0 0/1 * * ?" -->

<!-- Websphere
Compliant Thread :: Runs for every 5 mins -->

<task:scheduled-tasks
scheduler="timerScheduler" >

<task:scheduled
ref="testTask" method="run" cron="0 0/5 * * * ?"
/>

</task:scheduled-tasks
>

If you create the
scheduler like above , you can see the WebSphere Runtime available to thread
that executes this task , basically it is WebSphere managed thread

But if you use the
Spring's task scheduler directly (I mean without using the websphere
timemanager), thread that executes this task doesn't have access the Websphere
Runtime causing the J2EE container services are not available.

Same WAS profile can
be shared across the multiple RAD workspaces because profile is part of the
WebSphere Application Server (or WAS Test Environment ). Sharing of the same
WAS profile between the different workspaces is not recommended unless there is
only one active workspace at any time.

Following things
need to consider when sharing the profile

Avoid making the changes to
same application in different workspaces

Only one workspace is allowed
to debug at a given time

It always better to
create different WAS profile for each workspace if you are working on same
applications (e.g. same code base but parallel development branches or streams). Followings
steps makes easy to bring your new workspace with all configurations from your
old workspace (workspace preferences and profile configurations).

create new WAS
profile (for 32-bit Operating systems you can use the Profile Management
Tool in the RAD and for 64-bit operating systems you can use the
"interactive profile management tool" as described in this
article)

Once the profile is created
, add that profile to new workspace

Click
"new" in servers view

Select "Server
Type" and "Server Runtime" and click next

Select new profile that is
created in above step

click next to add any
applications in workspace to server.

Once the profile is added to
workspace , right click on the server profile and restore the old profile
configuration (you may need to copy the .car file that exported from the
old profile to this workspace folder ).

Start the server after
successful restore, Now you should see all configuration from old profile
here.

At very first step
of syndication is to check if both servers are able to communicate each other ,
So I just checked using "ping server1" from server2 and "ping
server2" from server1 and got no pocket loss and thought both are communicating
fine (Infrastructure team overlooked and confirmed that all ports are open , so
didn't validated at port level initially) .

From the above,
what we understood Subscriber is able to communicate with syndicator
(because we got response back) .

Solution in this case

We tried
creating the syndication pair from the server2 (syndicator) to server1
(subscriber) just to make sure the everything fine , then we found that
(server2)Syndicator is not able to communicate with subscriber(server1).
(Server1 to server2 is fine but not reverse).

Gone back
tried to validate the open ports between the servers (not just
"ping") , we tried telnet to that portal default port (10039)
and found that 10039 not open . This is basic thing we should have tried
this to make sure ports are open communicating over those ports are fine.