OC4j 9.3 support ?

Hi,
Is the freedownloadable JDeveloper 9.0.1.3 supports
remote/local debugging of OC4j 9.3 ?
Ramesh//

Check out the help system for details on Debugging.
Launch Help System
select "testing and optimizing application code"
select "debugging in JDeveloper"
select "debugging remote java programs"
select "remote debugging in OC4J"
raghu
JDev Team

Similar Messages

OC4J support local ejb?

It seems OC4J does not support local ELB, as it complains the local-home tag with session tag.

Hi Patrick,
As far as I know, OC4J only partially implements EJB 2.0 -- it
doesn't implement local interfaces. However, there are several,
different versions available. Which version are you using?
If you haven't already found it, there is a version of the pet
store application available for download from:
http://technet.oracle.com/sample_code/tech/java/oc4j/content.html
but it's an implementation of the 1.1.2 version.
Hope this helps,
Avi.

Does Oracle Application Server (10.1.3.4.0) support JSF 1.2?

Sorry for the double post, but I realized this was more appropriate in the OC4J forum so posted it there. Not sure how to delete this one :-(.
I am trying to migrate from JSF 1.1 to JSF 1.2 on OC4j 10.1.3.4.0 and am running in to problems. I recently stumbled on this post:
http://kjvarga.blogspot.com/2008/12/oc4j-1013-does-not-support-jsf-12.html
Which reads as follows:
I spent a very frustrating day wading through the version soup that is JavaServer Faces and trying to deploy a JSF 1.2 app on on OC4J 10.1.3 container. To save you a lot of time, OC4J DOES NOT SUPPORT JSF 1.2.
This technical paper explains that OC4J 10.1.3 (all versions) supports Servlet 2.4, JSP 2.0 and JSF 1.1.
http://www.oracle.com/technology/tech/java/oc4j/1013/whitepapers/OC4J-FOV-10131.pdf
And this handy webpage explains that "JSF 1.2 is the latest release and it works with servlet 2.5 and jsp 2.1". So obviously it's not compatible. It also details all the versions of Java technologies that each JSF version relies upon.
http://www.roseindia.net/jsf/jsf-versions.shtml
Is this true? I can't use the JSF spec released in 06 on the most current version of oracle application server? Could someone please confirm/deny/shed some light?
Thanks so much,
Yeuker
Edited by: yeuker on Jun 29, 2009 10:54 AM

Found a bit more information located here:
http://wiki.glassfish.java.net/Wiki.jsp?page=JavaServerFacesRI
See the section entitled
"Do I have to use a JSP 2.1/Servlet 2.5 container with the Mojarra version 1.2?" which states:
If you're using JSPs for your view descriptions, then yes, you will need to use a JSP 2.1/Servlet 2.5 compliant container. However, if you're using another view technology, such as Facelets or JSFTemplating, you can run JSF 1.2 within a Servlet 2.4 container with out issue.
Now here is the part that may make me look like a newb... not sure if I am "using JSP's for my view descriptions"... what does that mean anyway?
I dont think I am not using Facelets or JSFTemplating. I'm just using standard JSF... All of my pages end in jsp and the standard faces servlet that makes all *.faces requests go through the faces controller servlet. There is really no JSP EL code in my faces pages, just standard jsf tags h:form, f:selectItems, h:inputText etc...
So my question is... am I using JSP's for my view descriptions?

Second Forms Services OC4J Instance

What is a benefit of creating a Second Forms Services OC4J Instance In Oracle Application Server 10g?
In which cases it is a better to create a second oas OC4J instance than to create a new configuration section
in the same instance for new forms application ? Or such configuration with Second Forms Services OC4J Instance is supported by Oracle ?
Thank's

What's the alternative you're looking for?
If it is HTTPS to secure the communication - yes that's possible
If it's a plain socket connection in stead of HTTP - I think Oracle dropped that after version 6i, but I'm not 100% sure.
If it is traditional client-server - Oracle dropped that after version 6i.
So, please explain what is you want.

No way to use CMP in OC4J?

Hi, it seems we can never user CMP in OC4J.
OC4J does not support EJB-QL. So how can we implement the finder methods?
1) One way is to put finder methods in ejb home interface, and add implementation (using direct JDBC) in bean class. But the server could not find the correnspondent finder methods even we match them; Also, if we use findBy*** in home interface, and use ejbFindBy***, it still does not work.
2) Another option is to put finder method as an odinary business method in remote interface, and add implementation (using direct JDBC) in bean class. But, before we call this method, we must instantiate the bean by calling create() (without arguments, because we do not want to create record to db). We will get an error: Primary key was null.
So it seems we can never use CMP in OC4J, until it supports EJB-QL.
Thanks,

I use CMP all the time. OC4J (since it is based on Orion) should generate certain finder queries (except for perhaps the WHERE clause that you may have to add yourself to the orion-ejb-jar.xml file) for you just by entering them in the home interface. You can do advanced finders as well. What you need is the proper documentation:
Checkout:
http://kb.atlassian.com/content/orionsupport/articles/finders.html
http://kb.atlassian.com/content/orionsupport/articles/ejbfinderquery.html
as good places to start. No JDBC necessary!
Cheers
Ray
Hi, it seems we can never user CMP in OC4J.
OC4J does not support EJB-QL. So how can we implement the finder methods?
1) One way is to put finder methods in ejb home interface, and add implementation (using direct JDBC) in bean class. But the server could not find the correnspondent finder methods even we match them; Also, if we use findBy*** in home interface, and use ejbFindBy***, it still does not work.
2) Another option is to put finder method as an odinary business method in remote interface, and add implementation (using direct JDBC) in bean class. But, before we call this method, we must instantiate the bean by calling create() (without arguments, because we do not want to create record to db). We will get an error: Primary key was null.
So it seems we can never use CMP in OC4J, until it supports EJB-QL.
Thanks,

OC4J Plug in and IIS - What Software on the IIS box?

I want to configure an IIS server to use the OC4J plugin to route appropriate requests to OC4J.
The IIS server is a separate box and currently has no Oracle software installed.
What Oracle software (if any) does it need to run the OC4J Plugin? Just the opii.dll?
The manual makes reference to requiring permission changes in the ORACLE_HOME directory to allow HTTPS connections - but I don't have an Oracle Home on the IIS box. It seems like it's expected that IIS and OC4J are on the same machine - is this true?

i try to do quite the same .
i find that line in the documentation If Oracle Application Server is not installed on the same machine, then the standalone ONS daemon must be installed. OC4J Plug-in supports all the mod_oc4j functionality, including AJP over SSL and use of port tunneling
I don't know yet what does it means but .....

Version error in oc4j?

I've deployed a servlet testServlet in oc4j and when I load the servlet in browser, the following error occurs:
java.lang.UnsupportedClassVersionError:
company/abc/testServlet
(Unsupported major.minor version 48.0)
does anyone know why? Thanks.

Hi it_qoo,
Your version of OC4J does not support java version 1.4. Unfortunately, I could not find any details in your post as to what version of OC4J you are using. For certain OC4J versions, there are ways to configure it so that it does support java 1.4.
For your information, this topic has been discussed several times in the OC4J forum at Oracle's Technet Web site.
I suggest searching the forum archives for "1.4" and/or "48.0".
Good Luck,
Avi.

OPS$ Account Authentication in OC4J

Hi,
We have an existing database which uses OPS$ account authentication in Oracle Forms 6i. Fine.
But, I need to access the same database from a JSP Application deployed to OC4J. Does OC4J and JDBC support OPS$ authentication in any way?
Thanks,
Jeremy

HI,
Thanks for the response. Actually, I want all users to log in individually, rather than share a JDBC connection username and password. The users currently use Oracle Forms 6i and log in with the "/" username (which then uses remote authentication on the database).
The issue is that they I'm not able to use this kind of authentication via JDBC as, as far as I understand it, this is a feature of SQL*Net (which JDBC does not "use").
The workaround is that the users were created as "create user x identified by y" and not "create user x identified externally" so that they're able to log in both ways. I'm only able to do this because we're using the "OPS$" prefix.
1) using remote authentication
2) Explicitly specifying username and password.
Cheers,
Jeremy

AQ driven MDB in OC4J R2?

Hi,
Does anyone know if the full version of OC4J R2 will support Message Driven Beans instantiated from an AQ? I can see no mention of this in the preview version. If so what is the release date?
Cheers,
Matt

Hi,
the upcoming version will support AQ as a JMS provider.
Thanks,
Andy
Hi,
Does anyone know if the full version of OC4J R2 will support Message Driven Beans instantiated from an AQ? I can see no mention of this in the preview version. If so what is the release date?
Cheers,
Matt

Version error in Oracle oc4j

I've deployed a servlet testServlet in Oracle oc4j and when I load the servlet in browser, the following error occurs:
java.lang.UnsupportedClassVersionError:
company/abc/testServlet
(Unsupported major.minor version 48.0)
does anyone know why? Thanks.

Hi it_qoo,
Your version of OC4J does not support java version 1.4. Unfortunately, I could not find any details in your post as to what version of OC4J you are using. For certain OC4J versions, there are ways to configure it so that it does support java 1.4.
For your information, this topic has been discussed several times in the OC4J forum at Oracle's Technet Web site.
I suggest searching the forum archives for "1.4" and/or "48.0".
Good Luck,
Avi.

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

OC4J with Windows 7

Hi
I would like to know which version of OC4J container will support windows 7 OS (64 bit /32 bit ) If it is not supported please let me knwo when we canhave it
Thanks
Jacob

I have a WindowsXP host but I run my oc4j cluster on two Oracle Enterprise Linux 5.4 virtual machines using Sun VirtualBox.
If Windows 7 gives you problems then maybe VirtualBox is an alternative ?
Regards,
Ronald Wouters

OC4J with SSL

AOA
i want to know the complete the procedure to configure the OC4J with Digital Certificate.
Regrads
Aamar Nazir

You must implement SSL using the mod_ssl Module of Apache. OC4J does not support SSL on it's own.
Look for mod_ssl in the apache documentation for further details.

A few bugs in OC4J?

I encountered the following problems in developing OC4J. I'm not sure if they are bugs or just I did sth wrong.
1) OC4J does not support local bean, as it complains if I have local-home tag in ejb-jar.xml file;
2) OC4J does not support EJB-relation abstraction. For example, an orderheader can contains a few orderlines. If in the OrderheaderHome (CMP), we defined
public abstract void setOrderlines(Collection orderlines) and
public abstract Collection getOrderlines(),
the system will complain that we cannot declare the methods abstract. It seems we need implement those relations by ourselves.
3) OC4J does not generate SQl statements correctly based on the EJB-QL in ejb-jar.xml file. For example, I have a EJB-QL:
SELECT OBJECT(a) FROM OrderheaderEJB AS a WHERE customer_number = ?1
But after deployment, when I checked the SQl in orion-ejb-jar.xml, it is:

We missed the where part in the generated SQL.
Sometimes teh generated SQL is OK. So i am not sure if I did sth wrong here.
Thanks,

Hi Henry -
See inline.
I encountered the following problems in developing OC4J. I'm not sure if they are bugs or just I did sth wrong.
1) OC4J does not support local bean, as it complains if I have local-home tag in ejb-jar.xml file;OC4J does not yet support local interfaces - apparently this is coming soon (perhaps at Java One, don't know for sure)
2) OC4J does not support EJB-relation abstraction. For example, an orderheader can contains a few orderlines. If in the OrderheaderHome (CMP), we defined
public abstract void setOrderlines(Collection orderlines) and
public abstract Collection getOrderlines(),
the system will complain that we cannot declare the methods abstract. It seems we need implement those relations by ourselves.It does support relation abstraction, though it is slightly different from how the final spec ended up and should be cleaned up in the upcoming release or so. You mentioned putting the relationship abstractions in the Home file - I assume you mean the bean implementation file.
* Define ejb implementation class as abstract - i.e.
public abstract OrderheaderEJB ......
* Define all of the gets/sets that you expose in your remote
interface as abstract as well....
* Change your ejb-jar.xml file to an ejb2.0 style reference (change the dtd ref, etc)
Here is where the difference occurs that I mentioned above. In addition to your ejb-relationships section in your ejb-jar.xml file, you will also need to list the collection variable in your cmp-fields in your entity bean description.
For instance if your cmr-field-name is orderlines from the ejb-relationship section, create a cmp-field record for this as well. Again, this particular item should be cleaned up with the next release.
It should deploy just fine. I use this all the time.
3) OC4J does not generate SQl statements correctly based on the EJB-QL in ejb-jar.xml file. For example, I have a EJB-QL:
SELECT OBJECT(a) FROM OrderheaderEJB AS a WHERE customer_number = ?1
But after deployment, when I checked the SQl in orion-ejb-jar.xml, it is:

We missed the where part in the generated SQL.
Sometimes teh generated SQL is OK. So i am not sure if I did sth wrong here.OC4J does not yet support ejb-ql as I understand it - that release is a little further down the line as I understand it.
Cheers
Ray
Thanks,

Applets and OC4J

Hi,
we have developed an applet which calls EJBs deployed in OC4J.
The applet runs in the Java Plug-In 1.3.1. After granting the
privileges 'java.io.SerializablePermission "enableSubstitution"'
and 'java.lang.RuntimePermission "createClassLoader"' it
really worked, except that after a reload of the document the
browser hang, because the applet could not start. There is no
exception in the Java console.
1) Has anybody a clue where the problem is?
2) Will a future release of OC4J support applets without granting
these privileges, perhaps by supporting the standard RMI of sun.

Hi Elmar,
I'll respond to your questions in reverse order.
2. OC4J doesn't "support" applets, web browsers do (MSIE and
Netscape). Applet security restrictions are making you grant
permissions to allow you applet to create a custom class loader.
I really don't think these restrictions are going to be relaxed
in future (rather the opposite, I would imagine, if anything).
It is a known fact that Micro$oft Internet Explorer's JVM does
NOT support RMI (even though there is a patch for RMI support
buried deep in the bowels of Micro$oft's website), but if you are
using the plug-in, then you should have no trouble using RMI from
your applet.
1. I'm just guessing, but it could be that your custom class
loader class is being garbage collected by the web browser's JVM
whenever you leave the web page with the applet in it, so that
when you return to that web page, you can't reconnect to the EJB
since you don't have the classes you need in order to do it. I
suggest maybe moving your special class loading mechanisms to the
"start" method of the applet instead of the "init" method.
Good Luck,
Avi.

OC4j 9.3 support ?

Similar Messages

Maybe you are looking for