Is JMS 1.0.2 Supported in OC4J JMS 10.1.2 adaptor

Hi
I am wondering if JMS 1.0.2 is Supported in OC4J JMS 10.1.2 adaptor.
Thank you
Wade Adams
Message was edited by:
user617346

Just wanted to update with what I found out incase anyone else needs this information:
The SRE 505 eGate JMS Reference PDF file, indicates that SRE JMS is compliant with JMS version 1.0.2. In ICAN 505, the JMS server is compliant with JMS version 1.0.2b.
Also OC4j 10.1.2 adaptor is compliant iwth JMS version1.0.2b.

Similar Messages

XA Transaction Support In OC4J 10.1.2

Does OC4J support XA transactions using non emulated data sources? Or does 10.1.2 support XA transactions at all (across datasources-db or jms)?

The reason is that the commit coordinator lives in Oracle database for 10.1.2.x case. (you have to confiture the db link to do so)
In OC4J 10.1.3, the transaction manager has been re-implemented and the transaction coordination functionality is now located in OC4J, replacing in-database coordination, which is now deprecated. Also, the middle-tier coordinator is now "heterogeneous", meaning that it supports all XA-compatible resources, not just those from Oracle.
The middle tier coordinator provides the following features:
- Supports any XA compliant resource
- Supports interpositioning and transaction inflow
- Last Resource Commit Optimization
- Recovery Logging
-Frances

JSF 1.2 supported in OC4J (JDev 11g)

Hello Everyone,
How do you know if your container is supporting jsf 1.2 or not, as am wondering if Embedded OC4J in JDev 11g Technology Preview already supporting JSF 1.2 by default!?

Hi,
it does.
Frank

JAXB 2.0 Support for OC4J 10.1.3.3

http://java2go.blogspot.com/2008/01/jaxb-10-vs-20-in-jdeveloper-10g.html
This blog entry talks about how to get JAXB 2.0 in JDeveloper 10g. I want to know whether JAXB 2.0 is supported or not for OC4J 10.1.3.3, before i start using it in JDeveloper.
Chandresh.

Has anyone ever tried using spring web services with oc4j? I tried using JAXB 2.0. But it gives lot of errors while deploying the example.
Operation failed with error: Error creating bean with name 'messageReceiver' defined in class path resource [org/springframework/ws/samples/airline/ws/applicationContext-ws.xml]: Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.ws.server.endpoint.adapter.GenericMarshallingMethodEndpointAdapter#0': Cannot resolve reference to bean 'marshaller' while setting bean property 'marshaller'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'marshaller': Invocation of init method failed; nested exception is org.springframework.oxm.jaxb.JaxbSystemException: Provider com.sun.xml.bind.ContextFactory_1_0_1 not found; nested exception is javax.xml.bind.JAXBException: Provider com.sun.xml.bind.ContextFactory_1_0_1 not found - with linked exception: [oracle.classloader.util.AnnotatedClassNotFoundException: Missing class: com.sun.xml.bind.ContextFactory_1_0_1 Dependent class: javax.xml.bind.ContextFinder Loader: oracle.xml:10.1.0_2 Code-Source: /C:/oc4j/lib/xml.jar Configuration: (ignore manifest Class-Path) in META-INF/boot.xml in C:\oc4j\j2ee\home\oc4j.jar This load was initiated at airline.web.airline:0.0.0 using the loadClass() method. The missing class is not available from any code-source or loader in the system.]

Is "LIKE" supported in oc4j EJB QL

Hello,
I am wondering if any one has used "LIKE" statement in the finder methods.I have tried to change the query generated by oc4j but always get errors.
Is it supported in this release and how about future versions ?
Thank you

Hi Madani ,
Check the following link for ' LIKE ' usage in Custom finder method
http://www.mail-archive.com/[email protected]/msg16466.html
Hope this helps
--Venky

PDK-Java support for oc4j?

Hello. I am working with a customer who is responsible for building a web provider (the actual portal instance is being run by a separate division of the company). This customer is in the process of switching all of their generic servlet/jsps applications to the oc4j engine (now part of ias1022).
They are highly interested in running the pdk-java on oc4j as well, so that they do not have to manage both JServ and oc4j applications. I have noticed that the June PDK seems highly tied to Jserv (there are explicit references to servlet2.0 and oracle.jsp.JspServlet in the code). This would make it not port to oc4j and my tests confirm this.
Is there an announced roadmap for supporting the pdk-java on oc4j?
null

The next major release of PDK-Java will be Servlet 2.2 and hence OC4J compatible. You are right that the current version won't work in a Servlet 2.2 container, as it relies on ServletContext.getServlet(), a method which has been deprecated and returns null on Servlet 2.2.

JMX / MBeans Support in OC4J/JDev9i?

Hi all
Generally, is it possible to include self-written Managed Beans
(aka MBeans) into 9iAS? MBeans are components of the Java
Management Extension (JMX)
- If yes, where can I find a "How To" documentation?
- If no, at what time respectively in which release will be this
feature available in the future?
Thanx
Tino

Found something!
Not currently and not in the upcoming Oracle9iAS rel2. We are
looking into JMX support post rel2.

JMS Support

Hello,
I have a few questions about JMS Support in OC4J 9.0.3. Does the JMS implementation support clustering (load balancing and failover)? Is HTTP tunneling supported for client access to JMS? Is using AQ preferred over using the built in JMS implementation?
Len Takeuchi
Salescentrix.com

Hi John,
Thank you for your reply. Your reply and pointer to other info is extremely helpful. I was afraid that the questions were so general that no one would answer them.
Regards,
Len
Hi Len,
In 9iAS v9.0.3, OJMS (AQ/JMS) is the J2EE 1.3 compatible JMS provider. See the Oracle Metalink posting for more information
on OC4J/JMS and OJMS at http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=205305.1
Regarding JMS clustering, you need to look both at the JMS client and JMS provider. The JMS client, a servlet or MDB, is contained
within OC4J. The client then has all the high availabilty and load balancing features as does OC4J. I won't go into detail
here on those features since they're well documented on OTN and in the 9iAS documentation.
As for the JMS provider, which in OJMS's case is Oracle's Advanced Queuing, since AQ is in the 9iDB you have all the high availabity (RAC)
and load balancing available that you would normally get with 9iDB.
The closest thing to HTTP tunneling is the use of IDAP with OJMS. Take a look at the Advanced Queuing Developer's Guide for more
information on IDAP.
Hope this helps...
John

Which version of OC4J 9.0.2 or 9.0.3 supports jdk 1.4

does anybody know which version of OC4J 9.0.2 or 9.0.3 supports jdk 1.4??
thanks

OC4J v9.0.3 support JDK 1.4. By default OC4J standalone come with JDK 1.3.1.
Below are instructions to enable JDK 1.4 support in OC4J v9.0.3 standalone.
- Download JDK 1.4 from http://java.sun.com/
- Rename existing [OC4J_HOME]/jdk to [OC4J_HOME]//jdk131
[OC4J_HOME] - is the directory where oc4j_extended.zip was extracted
mv jdk jdk131
- copy JDK 1.4 with all the sub-directories into [OC4J_HOME]
cp -r <a jdk1.4> OR install JDK 1.4 into [OC4J_HOME]/jdk
Note: remember to name the directory jdk under [OC4J_HOME]
- The file jdk/jre/lib/security/java.security needs to be edited to include the following:
# Oracle specific definitions
auth.policy.provider=oracle.security.jazn.spi.PolicyProvider
login.configuration.provider=oracle.security.jazn.spi.LoginConfigProvider
The above steps will enable you to use OC4J under JDK 1.4.0
-Prasad

OC4J support for WS-CAF

Hello there! I'm new to oracle world, and I'd like to know how is the implementation/support of OC4J 10.1.2 and 10.1.3 of WS-CAF. We have an upcoming SOA project and one of the key aspects of it is the data integrity. I'd like to know how does Oracle AS deals with webservices transactions.
Regards

Hello,
WS-CAF (Web Services Composite Application Framework) is a work in progress, and the transaction protocols have not been completed yet. Oracle will support a protocol for distributed transactions in a coming release, once the industry has a standard in good shape enought to implement.
Regards
Tugdual Grall

Migrate the EJBs from JVM to OC4J...?

We are plan to migrate the EJBs modules from Oracle8i JServer to OC4J.
From now we have developed the EJBs by using JDeveloper as the following
conditions;
- JVM: Oracle8i JServer (8.1.6.3.0)
- EJBs: Session Beans only
- IDE tool: JDeveloper 3.2
And now we wanna migrate or re-deploy to the OC4J. Is there any good
suggestions or idea to do it? Also I wanna know sth to considerate...
Thanks in advance for any advice
Phyllis
null

It would be good for you to migrate to OC4J as performance in OC4J is a lot better. Here is a little migration writeup I had done sometime back. It is work in progress. Hope this helps.
Migrating EJB components from Database EJB container to OC4J
Author: Ashok Banerjee [[email protected]]
Oracle recommends the new J2EE containers in Oracle9iAS (OC4J) for deploying J2EE components. The goal of this paper is to recommend ways to migrate existing EJB applications, from database EJB container, to OC4J.
The database EJB container runs on the aurora session based Java Virtual Machine, whereas the new container runs on standard JDK (version 1.2.2 onward) .
The database EJB container runs in a database session. The database is itself the middle tier, in such a configuration. Users therefore have a logically three tiered architecture, that runs physically on two tiers. The database serves as both the middle tier and the backend. In such situations users would use the "kprb" driver (used for requests made from within the database). No further authentication is needed if the backend database is the same as the middle tier. Users can also use one database as the middle tier and another database as the backend.
In OC4J the middle tier does not require a database installation on the middle tier. This helps make the middle tier lightweight. OC4J is also seen to significantly faster than the EJB container inside the database. Since OC4J runs on regular JDK the user can run OC4J on the Java Virtual Machine which is best for his/her specific needs. OC4J however has a limitation in that does not support pure CORBA clients. Currently OC4J does not support RMI over IIOP either.
To migrate existing EJB applications from inside the database to OC4J the set of changes is minimal.
Code changes
1. Change all references in the code and any configuration files using JDBC URLs from kprb driver to either thin or oci. "kprb" driver is only for applications running inside the database. The new OC4J runs outside the database and therefore it must use thin or oci driver.
2. The database EJB container clientside JNDI lookups were like:
env.put (Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");
env.put (Context.SECURITY_PRINCIPAL, user);
env.put (Context.SECURITY_CREDENTIALS, password);
env.put (Context.SECURITY_AUTHENTICATION, ServiceCtx.NON_SSL_LOGIN);
Context ic = new InitialContext (env);
while in OC4J container the lookup code should read:
env.setProperty("java.naming.factory.initial","com.evermind.server.ApplicationClientInitialContextFactory");
env.setProperty("java.naming.provider.url","ormi://localhost");
env.setProperty("java.naming.security.principal","username");
env.setProperty("java.naming.security.credentials","password");
Context ic = new InitialContext (env);
3) Remove all references to oracle.aurora.* classes - they will not work with OC4J. These classes are specific to the container in the database.
4) Check for client demarcation of Bean Managed Transactions and remember that transaction in OC4J cannot be propagated across tiers. In other words client demarcated transaction will work provided the client is another EJB or a servlet in the same OC4J instance. This is also listed in the "Current Limitations" section.
Build changes
1. For EJB in the database we use loadjava to load classes into the database - this step is not necessary any longer for middle tier EJBs. The user merely needs to ensure that the classes are in the classpath.
2. Similarly the concept of resolver specification in the database EJB container ceases to be useful in OC4J. To make classes "findable" the user sets the classpath. In OC4J any jars in the $OC4J_HOME/lib directory are on the server side classpath of the application classloader. The user can also include classes in their own ear files before they deploy the ear. [If you do not know about the resolver specification, then you have not used it and do not need to know about it].
3. The database J2EE container did not have support for .ear files. The OC4J container supports J2EE standard .ear files. Both makefiles and ANT files are available in the code samples on OTN which show how to build ear files and also provides samples for the structure of the EAR files.
EAR File contains META-INF/application.xml
META-INF/orion-application.xml [optional]
applicationEjb.jar
applicationweb.war
applicationEjb.jar contains
META-INF/ejb-jar.xml
META-INF/orion-ejb-jar.xml
EJB classes
applicationWeb.war contains
WEB-INF/web.xml
WEB-INF/orion-web.xml
WEB-INF/lib/jar files needed
WEB-INF/classes class files needed for JSP servlets
For further information on how to write the xml files etc. please refer to their respective DTDs.
Both web.xml and ejb-jar.xml should be unaffected by the migration.
4. The deployejb tool used to deploy EJB to the database has been deprecated. In OC4J EJBs are deployed as shown below:
% java -jar admin.jar ormi://localhost:<rmi-port> userName password -deploy -file ejbdemo.ear -deploymentName jndiName
5. The ApplicationClientContainer does not need aurora_client.jar in the classpath instead it needs oc4j.jar in the classpath.
Configuration Changes:
1. In the database EJB container the configurations exist in database tables but in OC4J the configuration exists in industry standard XML files. By default these files are located at $OC4J_HOME/config directory. Users can start their OC4J instance with a different configuration using the -config switch to specify a different server.xml file.
%java -jar oc4j.jar -config config1/server1.xml
2. In the database EJB container scalability was achieved using the MTS architecture and session based Java Virtual Machine. In OC4J scalability is achieved by clustering and using the loadbalancer. For more details on loadbalancer please read <link to loadbalancer.doc>
3. The bindds tool used to bind data-sources to the JNDI namespace of the database EJB container is deprecated. In OC4J datasources are bound to the the namespace using the data-sources.xml in $OC4J_HOME/config. Non oracle data-sources can also be bound to the namespace. A typical entry in data-sources.xml could look like:
<data-source
class="com.evermind.sql.DriverManagerDataSource"
name="OracleDS"
location="jdbc/OracleCoreDS"
xa-location="jdbc/xa/OracleXADS"
ejb-location="jdbc/OracleDS"
connection-driver="oracle.jdbc.driver.OracleDriver"
username="scott"
password="tiger"
url="jdbc:oracle:thin:@dlsun1688:5521:jis2"
inactivity-timeout="30"
/>
4. Database EJB container used database authentication (database roles and database users) to authenticate users to the middle tier. OC4J uses principals.xml file to list groups and users and perform authentication. One can also implement UserManagers for OC4J to perform more complex authentication.
5. The ports used by OC4J for RMI, JMS and HTTP are all specified in rmi.xml, jms.xml, web-site.xml.
6. Both OC4J and the database container SSL (client authentication as well as server authentication).
7. The database EJB container could only be remotely debugged using a jdb like interface by starting a debugagent on the server, and a debugproxy on the client. OC4J containers on the other hand run on JDK and can be debugged with any debugger. This is very useful for debugging EJB/Servlet application running in the server.
8. The database EJB container comes with a database and hence has AQ (Advanced Queue) available for JMS. With OC4J there is a default in memory JMS implementation. OC4J server program can also connect to other JMS implementations(including AQ) using jms.xml. However a JNDI context may need to be implemented for AQ.
Current Limitations
1. The OC4J container at present does not support 2 phase commit.
2. The OC4J container at present does not support transaction context propagation across tiers. Hence client demarcated transactions are not supported in OC4J except where the client demarcating the transaction is in the same container, for example an EJB having its transaction demarcated by another EJB or servlet, in the same container.
3. In the classic container Oracle did not support RMI-IIOP tunneling through HTTP however in OC4J RMI over HTTP is supported.
null

Configuration of two-phase-commit in OC4J 10.1.2

Configuration of two-phase-commit in OC4J 10.1.2 in application with multiple modules
We have an application ear file consisting of ejb-modules (mdb and slsb) and two web-modules. We are using Oracle's advanced queueing for messaging and CMT (all ejb use the Required transaction attribute). We need different datasources (OrionCMTDataSource) including that for aq, so we need two-phase-commit. The web clients use ejbs and browse the messaging system. Our 'orion-application.xml' includes a commit-coordinator configuration, and the database is setup correctly. The configuration works fine for mdbs, when sending messages to the queues. When a client starts after messages have been sent and consumed by the mdbs, oc4j complains that no commit-coordinator is defined in 'server.xml'. If we start the client first, it can access the queues, but then the mdbs complain. It seems that the first one "gets" the commit-coordinator and the second one fails.
Some questions:
Why isn't the second client type using the commit-coordinator configuration of the "orion-application.xml"?
Is such scenario not supported by OC4J?
How can I setup the application correctly?
How do I configure commit-coordinator with different datasources to the same database? (Commit-Coordinator is also this database)

Take a look 'How to Use a Custom Serializer with Oracle Application Server Web Services' [1].
In your case, you should be looking at BeanMultiRefSerializer (org.apache.soap.encoding.soapenc), which will serialize your data using href and providing a way to deal with cycles.
All the best,
Eric
[1] http://www.oracle.com/technology/tech/webservices/htdocs/samples/serialize/index.html

Mapviewer servlet crash on OC4J 11g TP4

Hi!
Is it normal or not? If I try to deploy mapviewer.ear (10 or 11 pre) on OC4J 11G TP4 it make exception on
http://.../mapviewer/faces/home.jspx
Is it planing compatibility for these Oracle products? And on which release?

Mapviewer is not supported on OC4J 11g TP4.
Please note that the going forward position for Oracle Fusion Middleware R11 is that OC4J is being replaced with WebLogic Server.
-steve-

Transaction propagation from Oracle 8i or 9i to OC4J V2?

We have a very large Oracle 8i (8.1.6)-based application that uses PL/SQL exclusively for business logic; there are a few hundred user packages. We are considering a gradual introduction of EJB's into the mix, most likely via OC4J V2 when it is released.
Issue:
Because of the significant legacy of PL/SQL, it will be necessary to NOT ONLY be able to invoke PL/SQL and SQL from the EJB residing in the app server in a global transaction, BUT ALSO go the other direction: have a PL/SQL proc/function call out to an EJB in the app server. I theorize we can do this by setting up Java Stored Procedures that act as a facade for invoking EJB methods.
Scenario:
Oracle Forms web client invokes PL/SQL stored procedure, which invokes Java stored procedure, which looks up and invokes an EJB (EJB spec 2.0) in the app server, which invokes PL/SQL stored procedure or just plain SQL via JDBC.
Forms client -> PL/SQL SP -> Java SP -> EJB (on separate app server) -> PL/SQL or SQL.
Questions:
1) Assuming using OC4J V2 as the app server and Oracle 8.1.6 as database at both ends, will a transaction begun with the client (e.g. Forms 6i) propagate to all tiers of the call chain above? If not, why?
2) If it does work, is there anything special that must be coded in the Java stored proc, e.g. anything special usage of JTA?
3) Will it work the same in Oracle 8.1.6 and Oracle 9i?
4) Are there any problems using J2EE 1.3 API's from within Java stored procedures, given that Oracle 8i and 9i have backlevel built-in support for many of these features? In particular, I understand JServer has EJB 1.1 builtin, but what if I want to use an EJB 2.0 running in an external app server?
5) Are there any JTA incompatibilities between 8i/9i and J2EE 1.3 implementations (e.g. OC4J V2), particularly that would hamper this scenario?
6) If all is good so far, could I expect to replace OC4J with another J2EE 1.3 compliant app server (e.g. WebLogic or WebSphere) and still have same results?
7) Is it necessary to setup 2-phase commit in Oracle if the both the client-invoked and EJB-invoked databases in the above example are the same Oracle instance?

Hi Scott,
Answers appear below your questions...
Questions:
1) Assuming using OC4J V2 as the app server and Oracle 8.1.6 as database at both ends, will a transaction begun with the client (e.g. Forms 6i) propagate to all tiers of the call chain above? If not, why?Client side transactions are not supported (as far as I know), so
the answer is "no" and the reason is "not supported".
2) If it does work, is there anything special that must be coded in the Java stored proc, e.g. anything special usage of JTA?Irrelevant, since client-side transactions aren't supported.
3) Will it work the same in Oracle 8.1.6 and Oracle 9i?Yes, since neither 8i or 9i support client-side transactions.
Besides (again, as far as I know), both 8i and 9i both have the
same embedded JVM.
4) Are there any problems using J2EE 1.3 API's from within Java stored procedures, given that Oracle 8i and 9i have backlevel built-in support for many of these features? In particular, I understand JServer has EJB 1.1 builtin, but what if I want to use an EJB 2.0 running in an external app server? The database (8i and 9i) EJB container is not the same as OC4J. In
fact (as far as I know), Oracle recommends NOT using the embedded
container and using OC4J only. This means that in order for a java
stored procedure to lookup an OC4J EJB, you need to load the OC4J
JAR files into the database (via the "loadjava" tool). I haven't
tried it, but someone else posted to the forum saying he would try
it -- but I don't know how his experiment turned out. However, as
a workaround, you can use RMI in a java stored procedure. I have
successfully done this.
5) Are there any JTA incompatibilities between 8i/9i and J2EE 1.3 implementations (e.g. OC4J V2), particularly that would hamper this scenario?I don't know how to answer this question, sorry.
6) If all is good so far, could I expect to replace OC4J with another J2EE 1.3 compliant app server (e.g. WebLogic or WebSphere) and still have same results?Theoretically, J2EE compliant applications should be able to be
deployed and executed in any J2EE compliant application server.
However, another person in this forum had some difficulties in
migrating a ready built application from weblogic (I believe) to
OC4J. I think the problems were due to the application server
specific configuration differences (but I'm not sure).
7) Is it necessary to setup 2-phase commit in Oracle if the both the client-invoked and EJB-invoked databases in the above example are the same Oracle instance? I'm not sure about the status of two-phase commit support in OC4J.
Again, there is a (still unresolved, I think) thread in this forum
about some buggy commit behavious for CMP entity beans. However,
if you're asking this in the context of your scenarion (involving
client-side transactions), then it is moot, since, as I said earlier,
client side transactions are unsupported.
Hope this will help you,
Avi.

JMX on OC4J 10.1.2.0.0

Hello!
I've found some articles on JMX-support in OC4J (e.g. http://www.oracle.com/technology/tech/java/oc4j/1003/how_to/how-to-simplembeans/doc/readme.html), but never found any actual documentation on it. Is it something that has only appeared in the developer previews or is there any documentation on how it works somewhere?
Regards,
Bjorn Boe

Hmm. Looks like the API not fully implemented. Any idea how to back out the new implementation and use MX4J?
Error connecting: This part of the API is not supported
java.lang.UnsupportedOperationException: This part of the API is not supported
     at oracle.oc4j.admin.jmx.shared.UserMBeanServer.getClassLoaderRepository(UserMBeanServer.java:175)
     at oracle.oc4j.admin.jmx.server.state.LocalizationFilterMBeanServer.getClassLoaderRepository(LocalizationFilterMBeanServer.java:150)
     at javax.management.remote.rmi.RMIConnectionImpl$2.run(RMIConnectionImpl.java:1281)
     at java.security.AccessController.doPrivileged(Native Method)
     at javax.management.remote.rmi.RMIConnectionImpl.getClassLoaderRepository(RMIConnectionImpl.java:1278)
     at javax.management.remote.rmi.RMIConnectionImpl.access$000(RMIConnectionImpl.java:81)
     at javax.management.remote.rmi.RMIConnectionImpl$1.run(RMIConnectionImpl.java:132)
     at java.security.AccessController.doPrivileged(Native Method)
     at javax.management.remote.rmi.RMIConnectionImpl.<init>(RMIConnectionImpl.java:129)
     at javax.management.remote.rmi.RMIJRMPServerImpl.makeClient(RMIJRMPServerImpl.java:137)
     at javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:251)
     at javax.management.remote.rmi.RMIServerImpl.access$000(RMIServerImpl.java:59)
     at javax.management.remote.rmi.RMIServerImpl$2.run(RMIServerImpl.java:199)
     at javax.management.remote.rmi.RMIServerImpl$2.run(RMIServerImpl.java:198)
     at java.security.AccessController.doPrivileged(Native Method)
     at javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:196)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:585)
     at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
     at sun.rmi.transport.Transport$1.run(Transport.java:153)
     at java.security.AccessController.doPrivileged(Native Method)
     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
     at java.lang.Thread.run(Thread.java:595)
     at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
     at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
     at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
     at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown Source)
     at javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2229)
     at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:271)
     at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248)
     at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:207)

Is JMS 1.0.2 Supported in OC4J JMS 10.1.2 adaptor

Similar Messages

Maybe you are looking for