Re: The wonderfull worlds of encodings...
UTF Unicode Transfer Fromat can be many different lengths. UTF-8 uses 8 bit bytes to encode ISO-10646 code points. When the code point value is less than 65,768 (i.e. UNICODE) then UTF-8 will use up to 3 bytes (24 bits) to encode the code point. However, when the code point value is from the full 31 bit range of ISO-10646, then UTF-8 will use up to 7 bytes (56 bits) to encode the 31 bit value. There is also a UTF-16 encoding which sends 16 bit data units. Note: Java caracters are UNICODE, not ISO-10646. Java cannot represent code point values greater than 16 bits. BTW. if M$ is encoding unicode code points as % when it is sending UNICODE (16 bits per character) data, that is correct. HOWEVER, if used when sending 8-bit encodings such as UTF-8 this is a new M$ feature to lock in their customers. Tim - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, May 19, 2001 4:27 PM Subject: The wonderfull worlds of encodings... Hi, I've got a terible headache... It happens all the time I try to touch the bugs related with encodings - any of them... I'm sure you already know ( but I just found out ) what surrogate characters are. I know that UTF is _not_ 16 bits, but I had no idea it is 21 bits ( as opposed to UCS - 31 bits ). I'll try to get something working this weekend. Craig - you may want to take a look, the code in DefaultServlet is creating a writter for each encoding ( that's terribly expensive ), and doesn't seem to deal with surrogates ( well, the second part is not a problem - I doubt someone would use hieroglyphs or musical signs in a URL ). Now, the biggest problem is as ussually M$. From strange reasons, MSIE's javascript encode() method is generating % sequences instead of %XX%XX ( as most would expect ). That means the whole decoding might have to be rewritten 3.3 ( Apache doesn't deal with that either ). Question: what should happen with the context path ? It is supposed to be returned in the orignal form ( not decoded ) - but that can't work as a certain path can be encoded in many ways. I'm also not sure what should happen if web.xml and in server.xml ( where path is defined ) - should we use %xx encoded URLs ? But what would that mean for characters that have multiple encodings ? The solution I have in mind right now is to keep doing all the mappings and process web.xml - and do all internal operations with decoded characters, while keeping the original form for the facade, so servlets get what they expect. Any ideas ? I'm not sure I can handle this. Costin
Re: [tomcat 4] RequestUtil.parseParameters() method
I remember this code. It is correct given previous development history.
The bytes in the input data string are NOT encoded.
The look back earlier to where the original byte array from the browser is
converted to a string. You will notice that no encoding is applied to the
bytes as they are stored in the string ( I.E. the input loop is:
while () {
int x = read(); //which reads a 8 bit byte
from the stream
string[i] = x; //which assumes that each
byte is a character
}
Therefore, the deprecated getBytes method undoes this damage converting the
bytes back into a byte array so an encoding can be applied to the bytes and
a correctly encode character string produced.
The input data to this method should have always been a byte array but for
some reason previous developers converted the byte array into a string which
only holds 8 bit characters.
Tim
- Original Message -
From: kevin seguin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, May 13, 2001 10:02 PM
Subject: [tomcat 4] RequestUtil.parseParameters() method
i just happened to be looking through the RequestUtil.parseParameters()
method, and something struck me as odd. since i don't know the history
here, i figured i'd ask someone who does...
anyway, the method looks something like this:
public static void parseParameters(Map map, String data, String
encoding)
throws UnsupportedEncodingException {
if ((data != null) (data.length() 0)) {
int len = data.length();
byte[] bytes = new byte[len];
data.getBytes(0, len, bytes, 0);
parseParameters(map, bytes, encoding);
}
}
what strikes me as odd is an encoding is being passed into the method,
but rather than using this encoding to get the bytes out of the string
passed in, a deprecated getBytes method is being used. also, to
determine the number of bytes to get, String.length() is being used.
this is a potential problem because String.length() is the number of
unicode characters, which is not necessarily the same number of bytes in
the string (think multibyte character sets).
i believe a safer version of this method is:
public static void parseParameters(Map map, String data, String
encoding)
throws UnsupportedEncodingException {
if ((data != null) (data.length() 0)) {
byte[] bytes = data.getBytes(encoding);
parseParameters(map, bytes, encoding);
}
}
RequestUtil.URLDecode(String str, String enc) has a similar problem.
i can commit changes to fix these problems if that's ok (i'm a new
committer, so i figure before i go stepping on anybody's toes, i'd run
this by the list :) ...
-kevin.
Re: Multi-Byte character support.
I have helped work on a fix for this on 4.0 (which supports the javax.servlet.ServletRequest.setCharacterEncoding() method). Tomcat 3.x does not support the new servlet 2.3 methods, so I did not look at fixing it in Tomcat. However, I have an easy to use object (included) which is able to process the mangled string and convert it to the encoding that you specify. This method will work for all Strings parsed into Tomcat (or other web servers). Tim Tye T. Park writes: Greetings, Tomcat 3.2[.1] doesn't seem to like static html pages (or servlets for that matter) that offer multi-byte (non-latin) characters. Has anyone coded a patch to fix this and/or have a workaround for the issue. I'd rather avoid having to re-invent the wheel. Does anyone have any insights as to how big a problem this is to fix? Cheers, Thom -- http://www.borland.com/newsgroups http://www.borland.com/devsupport/disclaim.html ChangeStringEncoding.java
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory EjbFactory.java
I am happy with this version of EjbFactory. Thanks, Tim Tye [EMAIL PROTECTED] writes: remm01/03/20 15:17:37 Modified:catalina/src/share/org/apache/naming/factory EjbFactory.java Log: - Comment out the type checking, as suggested by Tim Tye. Revision ChangesPath 1.6 +10 -10 jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java
Re: Strange problem with URL_PKG_PREFIXES
Remy Maucherat writes: I've updated the object factory for the EJB references. It should now attempt to resolve ejb-links using a JNDI lookup. I can't really test the feature, so I'm waiting for your feedback and stack traces, if it goes wrong ;-) Remy Ok, I will test with the 20010320 nightly build when it is available. (I cannot access all of the Java code I need to build tomcat at work because of a parinoid fire wall). Tim
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory EjbFactory.java
This code does not work because the classloader is different than the
servlet class loader. The "Class home = Class.forName(homeClassName);"
line fails with "Class.forName() failed: java.lang.ClassNotFoundException:
cool.models.coop07.java.S_STRESS_31KpsHome".
This same line works in the servlet.
Actually, I do not think the test of class type returned is necessary.
When it is eliminated, the servlet will get an exception when casting the
remote object to the home interface anyway (assuming some type of problem).
Otherwise, it works and less code is executed.
Also, if this were an LDAP/IIOP class, ordinary class casting will not
work, the servlet would be using "PortableRemoteObject.narrow(...)"
instead.
So, my suggestion is to erase lines:
+String homeClassName = ref.getClassName();
+Class home = Class.forName(homeClassName);
+if (home.isInstance(beanObj)) {
+} else {
+throw new NamingException
+("Bean of type " + beanObj.getClass().getName()
+ + " doesn't implement home interface "
+ + home.getName());
+}
And leave only line:
+return beanObj;
Tim
[EMAIL PROTECTED] writes:
remm01/03/19 17:21:07
Modified:catalina/src/share/org/apache/naming/factory EjbFactory.java
Log:
- Use the specified ejb-link to resolve the EJB reference.
- Will do a JNDI lookup using the URL specified.
- Will also check the type of the bean returned, and check if it implements
the home interface specified in the reference.
Revision ChangesPath
1.3 +27 -3
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java
Index: EjbFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- EjbFactory.java 2001/01/23 03:43:53 1.2
+++ EjbFactory.java 2001/03/20 01:21:05 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
1.2 2001/01/23 03:43:53 remm Exp $
- * $Revision: 1.2 $
- * $Date: 2001/01/23 03:43:53 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
1.3 2001/03/20 01:21:05 remm Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/03/20 01:21:05 $
*
*
*
@@ -67,6 +67,7 @@
import java.util.Hashtable;
import javax.naming.Name;
import javax.naming.Context;
+import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.naming.Reference;
import javax.naming.RefAddr;
@@ -77,7 +78,7 @@
* Object factory for EJBs.
*
* @author Remy Maucherat
- * @version $Revision: 1.2 $ $Date: 2001/01/23 03:43:53 $
+ * @version $Revision: 1.3 $ $Date: 2001/03/20 01:21:05 $
*/
public class EjbFactory
@@ -110,6 +111,27 @@
if (obj instanceof EjbRef) {
Reference ref = (Reference) obj;
+
+// If ejb-link has been specified, resolving the link using JNDI
+RefAddr linkRefAddr = ref.get(EjbRef.LINK);
+if (linkRefAddr != null) {
+// Retrieving the EJB link
+String ejbLink = linkRefAddr.getContent().toString();
+Object beanObj = (new InitialContext()).lookup(ejbLink);
+// Load home interface and checking if bean correctly
+// implements specified home interface
+String homeClassName = ref.getClassName();
+Class home = Class.forName(homeClassName);
+if (home.isInstance(beanObj)) {
+return beanObj;
+} else {
+throw new NamingException
+("Bean of type " + beanObj.getClass().getName()
+ + " doesn't implement home interface "
+ + home.getName());
+}
+}
+
ObjectFactory factory = null;
RefAddr factoryRefAddr = ref.get(Constants.FACTORY);
if (factoryRefAddr != null) {
@@ -138,6 +160,7 @@
}
}
}
+
// Note: No defaults here
if (factory != null) {
return factory.getObjectInstance
@@ -146,6 +169,7 @@
throw new NamingException
("Cannot create resource instance");
}
+
Re: Strange problem with URL_PKG_PREFIXES
Remy Maucherat writes:
Quoting [EMAIL PROTECTED]:
Remy Maucherat writes:
I've updated the object factory for the EJB references. It should now
attempt to resolve ejb-links using a JNDI lookup.
I can't really test the feature, so I'm waiting for your feedback and
stack
traces, if it goes wrong ;-)
I finally got all pieces downloaded and compiled the change
Now we get an exception on the correct class name...:
S_STRESS_31K [true] | org.apache.naming.EjbRef |
javax.naming.NamingException:
cool.models.coop07.java.S_STRESS_31KpsHome
javax.naming.NamingException:
cool.models.coop07.java.S_STRESS_31KpsHome
The exception isn't very clear. It can't load the home interface, right ?
To debug that problem, the factory won't fail if loading of the home interface
fails or if the type checking fails. If something like that happens, a message
will be printed out on the console, but the bean instance will still be
returned.
However, if the factory can't load the home interface class, your servlet will
probably not be able to either (which is a problem).
Remy
Please do not test the class of the REMOTE OBJECT returned from the EJB
server.
The servlet has no problem loading or casting the remote object to the home
interface class because the servlet classes include the EJB client classes.
The actual object name of the remote object is $Proxy??? (where ??? is a
number between 0 and 999).
That proxy object represents the Home Interface and can be cast to the home
interface. But the remote object cannot be tested correctly with the
'Class' object.
Please use the following code snip, it includes the only test that actually
succeeds.
if (linkRefAddr != null) {
// Retrieving the EJB link
String ejbLink = linkRefAddr.getContent().toString();
Object beanObj = null;
try {
beanObj = (new InitialContext()).lookup(ejbLink);
String homeClassName = ref.getClassName();
if (!homeClassName.endsWith(beanObj.toString()))
System.out.println("EJB link \"" + ejbLink
+ "\" of EJB Object: " + beanObj
+ " is not castable to: " + homeClassName);
} catch (Exception e) {
System.out.println("EJB link \""+ejbLink+"\" failed: "+e);
}
return beanObj;
}
Tim
Re: Strange problem with URL_PKG_PREFIXES
Remy Maucherat writes:
Quoting [EMAIL PROTECTED]:
I am trying to make the ejb-link use jnp://ttt1:1099/EJBresource work.
So it doesn't work either the other way around ?
No: ...
When I call 'lc = (Context)ctx.lookup("jnp://ttt1.ca.com:1099");' in any
form, I get "javax.naming.NameNotFoundException: Name jnp: is not
bound in this Context"
When I encode the URL in the ejb-link I get
"javax.naming.NamingException: Cannot create resource instance"
I need to resolve this type of URL link in Jakarta to allow seperation
between the JSP server and the EJB server.
The org.apache.naming.NamingContext does not seem to pass the correct
information to NamingManager so it can connect to the jnpURLNaming
Can you think of anything else to try?
If you call (new InitialContext()).lookup("jnp://ttt1:1099/EJBresource"), then
it's supposed to work if the jnp URL context factory is in the classpath.
Nothing special has to be done in NamingContext (the same is true for the java
URLs and JNP - that's why I can't figure out why it doesn't work).
Re: Strange problem with URL_PKG_PREFIXES
Remy Maucherat writes:
Remy Maucherat writes:
Quoting [EMAIL PROTECTED]:
I am trying to make the ejb-link use jnp://ttt1:1099/EJBresource
work.
So it doesn't work either the other way around ?
No: ...
When I call 'lc = (Context)ctx.lookup("jnp://ttt1.ca.com:1099");' in any
form, I get "javax.naming.NameNotFoundException: Name jnp: is not
bound in this Context"
When I encode the URL in the ejb-link I get
"javax.naming.NamingException: Cannot create resource instance"
I did some testing on this.
The integrated ENC was running fine even if the JNP URL prefix was appended
before org.apache.naming (I had put jnpserver.jar in common/lib).
However, trying to resolve a jnp: URL always failed :-(
It could be a classloader problem after all. Where did you put the jnp JAR
and its dependencies (if any) ?
I placed a link to jnp-client.jar in file:/usr/java/jdk1.3/jre/lib/ext/.
When I reference the libraries via InitialContext(env) as:
Hashtable env = new Properties();
env.put("java.naming.factory.initial",
(String)lc.lookup("env/ejb/naming/factory"));
env.put("java.naming.provider.url",
(String)lc.lookup("env/ejb/naming/provider"));
Context jb = new InitialContext(env);
Everything is found and works correctly.
However, reference via ctx.lookup("jnp") always fails.
BTW, Even when I remove the jnp-client.jar from lib/ext, the InitialContext
lookup works.
Remy
Re: Strange problem with URL_PKG_PREFIXES
I've got some of the lookup working now, but ejb-link still fails:
WORKS-- lc = (Context)ctx.lookup("jnp://ttt1.ca.com:1099");
WORKS-- ho =
(EJBHome)ctx.lookup("jnp://ttt1.ca.com:1099/S_STRESS_31Kps");
FAILS--- ho = (EJBHome)ctx.lookup("java:/comp/ejb/S_STRESS_31K");
Web.xml entry:
ejb-ref
descriptionSample bean generated by coolgen placed here for ease
of early testing/description
ejb-ref-nameejb/S_STRESS_31K/ejb-ref-name
ejb-ref-typeSession/ejb-ref-type
homecool.models.coop07.java.S_STRESS_31KpsHome/home
remotecool.models.coop07.java.S_STRESS_31Kps/remote
ejb-linkjnp://ttt1.ca.com:1099/S_STRESS_31Kps/ejb-link
/ejb-ref
javax.naming.NamingException: Cannot create resource instance
at org.apache.naming.NamingContext.lookup(NamingContext.java:837)
at org.apache.naming.NamingContext.lookup(NamingContext.java:181)
at org.apache.naming.NamingContext.lookup(NamingContext.java:822)
at org.apache.naming.NamingContext.lookup(NamingContext.java:181)
at org.apache.naming.NamingContext.lookup(NamingContext.java:822)
at org.apache.naming.NamingContext.lookup(NamingContext.java:194)
at org.apache.naming.SelectorContext.lookup(SelectorContext.java:183)
at javax.naming.InitialContext.lookup(InitialContext.java:350)
at SimpleServlet.printContextInfo(SimpleServlet.java:177)
at SimpleServlet.doIt(SimpleServlet.java:99)
at SimpleServlet.doGet(SimpleServlet.java:29)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:534)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:325)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:262)
at
org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:386)
at
org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:144)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:211)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:211)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:254)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:468)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2119)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:446)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:162)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:818)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:893)
at java.lang.Thread.run(Thread.java:484)
Remy Maucherat writes:
Remy Maucherat writes:
Re: Strange problem with URL_PKG_PREFIXES
Thanks, I look forward to the final patch.
I placed jnp-client.jar in jdk1.3/jdk/lib/ext and removed a hand build jar
(containing only jnpURLContextFactory) in jakarta-tomcat-4.0/common/lib.
Finally, setting
"java.naming.factory.url.pkgs = org.apache.naming:org.jnp.interfaces".
Tim
Remy Maucherat writes:
Quoting [EMAIL PROTECTED]:
I've got some of the lookup working now, but ejb-link still fails:
WORKS-- lc = (Context)ctx.lookup("jnp://ttt1.ca.com:1099");
WORKS-- ho =
(EJBHome)ctx.lookup("jnp://ttt1.ca.com:1099/S_STRESS_31Kps");
FAILS--- ho = (EJBHome)ctx.lookup("java:/comp/ejb/S_STRESS_31K");
Wahoo, way cool :-)
I think I can easily fix the last one by applying a simple patch to the EJB
object factory.
BTW, how did you fix your problems ?
Remy
Re: Strange problem with URL_PKG_PREFIXES
Remy, Thanks for helping me look into this problem. I believe that short term, prepending the apache pkg prefix is a simple way to make results consistent. I thought that some of my problem might be from having out of date 'org.jnp.interface' library. I have looked all morning, and cannot find anything outside of JBoss that includes this jar, so I have no explaination why Jakarta is able to get a naming context from JBoss instead of Class load fail!!! How do I find out where a servlet class loader is obtaining a class from (which jar path)? I am trying to make the ejb-link use jnp://ttt1:1099/EJBresource work. I need to resolve this type of URL link in Jakarta to allow seperation between the JSP server and the EJB server. The org.apache.naming.NamingContext does not seem to pass the correct information to NamingManager so it can connect to the jnpURLNaming Can you think of anything else to try? Remy Maucherat writes: According to NamingManager documentation, first it will look for 'org.jnp.interfaces.java.javaURLContextFactory' which does not exist, so it should next look for 'org.apache.naming.java.javaURLContextFactory' which does exist. So, this should work. Indeed, my mistake. It should work, since the IC will only call lookup on the Context produced by the IC factory *after* checking the URLs. BTW, the 'org.apache.naming' prefix is concatenated onto the URL prefixes by jakarta. Since I can't figure out where the problem is coming from, I can change it and make 'org.apache.naming' a prefix. Also, when the jnp.jar is removed, it still fails with the same error. How can this be made to work? Don't you get a no initial context factory found when you remove JNP ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: ejb-ref/EjbRef/EjbFactory implementation
I am very interested in this implementation. I have been trying to use the
tomcat context to get a reference to an EJB in another machine (running
Jboss).
In my investigation, the ejb-link is the most important field in
ejb-ref when there are multiple machines because it defines the full URL
to the EJB
(schema://machine.url:port/published.ejb.name).
The NamingManager should be able to use the schema to find the
URLContextFactory. And the 'machine.url:port' for the connection.
The home remote and other tags are useful, when the EJB containter is
sharing the same JVM as jakarta (and thus the same name space).
Please send me more details of your implementation.
Thanks, Tim
Arnaud Level writes:
Hi everyone,
I'm working on the implementation of the EjbFactory class (Tomcat 4.0).
According to what I've understand, this class is used when the lookup
method is called from a Servlet (or jsp).
e.g: Context ctx = new InitialContext();
ctx.lookup("java:comp\MyEjb");
If the ejb-ref tag has been defined in the web.xml file, Tomcat is able
to find the EjbFactory (through the EjbRef saved for MyEjb). Then what
can this Factory do ?
It delegates the job to the Ejb server in its getObjectInstance method:
- by creating a new InitialContext (with the factory class of my Ejb
server as env parameter).
- by calling the lookup method of the newly created context and
returning the resulting value.
If this is correct, what the point to define the home,remote and
ejb-link (in the web.xml file) value since they are not passed to the
Ejb server which will use the one defined in its own web.xml file. So
the question is what are those value (defined in the web.xml file of
read by Tomcat) used for ?
Am I misundertanding something ?
Any help is appreciated.
Thank you.
Arnaud Level.
This is a basic way to implement it but it shows the idea:
e.g: EjbFactory.java
public Object getObjectInstance(Object obj, Name name, Context
nameCtx,
Hashtable environment)
throws NamingException {
if (obj instanceof EjbRef) {
Reference ref = (Reference) obj;
Hashtable table = new Hashtable(2);
table.put(Context.INITIAL_CONTEXT_FACTORY,
"com...MyEjbServerCtxFactory");
javax.naming.InitialContext initCtx = new
javax.naming.InitialContext(table);
return initCtx.lookup("MyEjb"); //
}
return null;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Strange problem with URL_PKG_PREFIXES
The Context.URL_PKG_PREFIXES environment variable is a colon-seperated list
of package prefixes. However, when I set this environment variable to
"org.jnp.interfaces:org.apache.naming" and attempt to get a Context;
Context ctx = new InitialContext().lookup("java:/comp");
The lookup fails with:
javax.naming.ConfigurationException: Provider URL missing
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:702)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:286)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:279)
at javax.naming.InitialContext.lookup(InitialContext.java:350)
at SimpleServlet.printContextInfo(SimpleServlet.java:153)
at SimpleServlet.doIt(SimpleServlet.java:99)
at SimpleServlet.doGet(SimpleServlet.java:29)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:534)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:325)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:262)
at
org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:386)
at
org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:144)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:211)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:211)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:254)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:201)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:468)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2119)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:446)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:162)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:879)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:818)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:893)
at java.lang.Thread.run(Thread.java:484)
However, when I set this environment variable to
"org.apache.naming:org.jnp.interfaces"
The lookup succeeds!
"org.jnp.interfaces" only contains one class and that is
"org.jnp.interfaces.jnp.jnpURLContextFactory".
It seems to me that the lookup code is not correctly parsing the
Context.URL_PKG_PREFIXES environment variable.
Tim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
ejb-ref ejb-link Implementation in 4.0.b1
I am trying to obtain a remote reference to an EJB in another machine.
I have set the ejb-ref in web.xml as follows:
ejb-ref
descriptionSample bean generated by coolgen placed here for ease of
early testing/description
ejb-ref-nameejb/S_STRESS_32K/ejb-ref-name
ejb-ref-typeSession/ejb-ref-type
homecool.models.coop07.java.S_STRESS_32KpsHome/home
remotecool.models.coop07.java.S_STRESS_32Kps/remote
ejb-linkjndi:/ttt1.ca.com:1099/S_STRESS_32Kps/ejb-link
/ejb-ref
However, when I do ctx.lookup("java:/comp/ejb/S_STRESS_32K") I get a null
reference instead of the necessary remote reference to the home interface.
Is ejb-link implemented and documented?
Which code is involved in ejb-link lookup?
Is this fixed in the latest 4.0?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: ejb-ref ejb-link Implementation in 4.0.b1
Weining Qi writes:
if you are running tomcat 3.x in the same window (tomcat run), look at the
feedback from tomcat when call the ejb that way, you can see that tomcat
does not recognize the namespace "java:com/env/" for calling ejb as
The name is "java:comp/ejb" NOT --.
And yes tomcat does recognize it
Because it is defined in web.xml as shown in the snip.
the sun j2ee specification v1.3. you should call ejb directly by its jndi
name, which you gave when you deployed it.
I tried that, it does not work. I get "NamingException".
Note: the EJB is deployed in a different machine than tomcat.
When I try to open the context to that machine directly from a servlet in
tomcat, I get:
javax.naming.NoInitialContextException: Cannot instantiate class:
org.jnp.interfaces.NamingContextFactory. Root exception is
java.lang.ClassCastException: org.jnp.interfaces.NamingContextFactory
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:659)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:250)
at javax.naming.InitialContext.init(InitialContext.java:226)
at javax.naming.InitialContext.init(InitialContext.java:202)
at SimpleServlet.printContextInfo(SimpleServlet.java:168)
at SimpleServlet.doIt(SimpleServlet.java:99)
at SimpleServlet.doGet(SimpleServlet.java:30)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:573)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:321)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:236)
at
org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:386)
at
org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:144)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:180)
at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:180)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:251)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:196)
at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:464)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2041)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:159)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:818)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:897)
at java.lang.Thread.run(Thread.java:484)
YET: this same code works when I run it from a standalone Java application.
I believe that tomcat's InitialContext() is preventing the remote
connection from being established.
Weining
Weining Qi
RabobankICT and Info.nl, Amsterdam
IPO, TU/e, Eindhoven, The Netherlands
http://weining.n3.net/
Tel: +31.628161183
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, March 09, 2001 5:55 PM
Subject: ejb-ref ejb-link Implementation in 4.0.b1
I am trying to obtain a remote reference to an EJB in another machine.
I have set the ejb-ref in web.xml as follows:
ejb-ref
descriptionSample bean generated by coolgen placed here for ease of
early testing/description
ejb-ref-nameejb/S_STRESS_32K/ejb-ref-name
ejb-ref-typeSession/ejb-ref-type
homecool.models.coop07.java.S_STRESS_32KpsHome/home
remotecool.models.coop07.java.S_STRESS_32Kps/remote
ejb-linkjndi:/ttt1.ca.com:1099/S_STRESS_32Kps/ejb-link
/ejb-ref
However, when I do ctx.lookup("java:/comp/ejb/S_STRESS_32K") I get a null
reference instead of the necessary remote reference to the home
