You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Tomasz Mazan <wi...@wp.pl> on 2007/08/17 12:51:31 UTC
Is there any reason to use @Remote for session bean...
..if there's no global jndi context and I can't get SBean within my
standalone java application client?
In addition - there's no chance to run old EJB2 application with remote
client on Geronimo 2.0. May I'm wrong - so, please help me to understand
this "feature".
best regards
Beniamin
--
View this message in context: http://www.nabble.com/Is-there-any-reason-to-use-%40Remote-for-session-bean...-tf4285008s134.html#a12197581
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Is there any reason to use @Remote for session bean...
Posted by Tomasz Mazan <wi...@wp.pl>.
>> David, I can't say what I've done wrong before, but when I reorganize
>> my apllication (and deploy as ear) in many aspects, Remote interface
>> works fine :) I have to reply to your doubt - bean class implements
>> CustomerFacade remote interface.
>
> Wow, that's interesting. How was it organized before? Definitely
> seems like something we'll want to watch out for.
>
David, All circumstances points that there was some kind of stupid
error. I've just reorganized back my project (deploy as single jar) and
all works. Sorry for unnecessary muddle and asking you for help.
>>> The fact that we can't get logging statements is a big issue.
>>> Filled a jira for this one (GERONIMO-3445).
>>>
>> I've modified logger config like:
>> #log4j.appender.CONSOLE.Threshold=${org.apache.geronimo.log.ConsoleLogLevel}
>>
>> log4j.appender.CONSOLE.Threshold=INFO
>> and I've seen some more messages. There's no change in subject of
>> "OpenEJB jndi messages" but my problem primary problem was resolved.
>
> That's good that you're getting more messages. We'll have to see what
> we can do about the jndi name log messages as that is by far the
> easiest way to communicate someone what to lookup.
>
>> Thank You for your help
>
> Thanks for hanging in there! We like it when people ask for help,
> helps us make things better. We appreciate it.
Oh, I'm going to make production implementation of our system using
Apache Geronimo, so I couldn't give up :-) I hope that my real as well
as unreal (like that jndi name and remote interface) problems will be
helpful to improve your product.
Best regards
Tomasz Mazan
Re: Is there any reason to use @Remote for session bean...
Posted by David Blevins <da...@visi.com>.
On Aug 28, 2007, at 9:57 AM, Tomasz Mazan wrote:
> David Blevins pisze:
>>> I'll must to investigate context using servlet to find all beans,
>>> because Your advice (EJBtest-1.0.jar/CustomerFacade(Impl)/
>>> com.your.package.CustomerFacade) hasn't helped me - I get
>>> NameNotFoundException :-(
>>
>> Definitely give that a try. I wonder, does your bean class
>> implement the CustomerFacade remote interface? If not than maybe
>> you don't have any proxies at all -- we wouldn't have seen the
>> interface. Just kind of grabbing at straws :)
>>
>> Looking forward to the output of the servlet.
>>
> David, I can't say what I've done wrong before, but when I
> reorganize my apllication (and deploy as ear) in many aspects,
> Remote interface works fine :) I have to reply to your doubt -
> bean class implements CustomerFacade remote interface.
Wow, that's interesting. How was it organized before? Definitely
seems like something we'll want to watch out for.
>> The fact that we can't get logging statements is a big issue.
>> Filled a jira for this one (GERONIMO-3445).
>>
> I've modified logger config like:
> #log4j.appender.CONSOLE.Threshold=$
> {org.apache.geronimo.log.ConsoleLogLevel}
> log4j.appender.CONSOLE.Threshold=INFO
> and I've seen some more messages. There's no change in subject of
> "OpenEJB jndi messages" but my problem primary problem was resolved.
That's good that you're getting more messages. We'll have to see
what we can do about the jndi name log messages as that is by far the
easiest way to communicate someone what to lookup.
> Thank You for your help
Thanks for hanging in there! We like it when people ask for help,
helps us make things better. We appreciate it.
-David
Re: Is there any reason to use @Remote for session bean...
Posted by Tomasz Mazan <wi...@wp.pl>.
David Blevins pisze:
>> I'll must to investigate context using servlet to find all beans,
>> because Your advice
>> (EJBtest-1.0.jar/CustomerFacade(Impl)/com.your.package.CustomerFacade)
>> hasn't helped me - I get NameNotFoundException :-(
>
> Definitely give that a try. I wonder, does your bean class implement
> the CustomerFacade remote interface? If not than maybe you don't have
> any proxies at all -- we wouldn't have seen the interface. Just kind
> of grabbing at straws :)
>
> Looking forward to the output of the servlet.
>
David, I can't say what I've done wrong before, but when I reorganize my
apllication (and deploy as ear) in many aspects, Remote interface works
fine :) I have to reply to your doubt - bean class implements
CustomerFacade remote interface.
>>> As a last resort, you can change this line in server-log4j.properties:
>>> -log4j.rootLogger=ERROR, CONSOLE, FILE
>>> +log4j.rootLogger=INFO, CONSOLE, FILE
>>>
>>> That should *definitely* do it, but the flood gates will be open :)
>> Only one, additional item of "flood" is MEJBGBean exception:
>>
>> Module 6/36
>> org.apache.geronimo.configs/cxf/2.0-M6/car
>> 11:14:45,906 WARN [startup] Unable to scrape for @Stateful, @
>> Stateless or @MessageDriven annotations. EjbModule URL not valid:
>> MEJBGBean
>> java.net.MalformedURLException: no protocol: MEJBGBean
>>
>> ... and no messages about jndi. Strange
>
> The MalformedURLException can safely be ignored, that's just a message
> we need to clean up. The fact that we can't get the log messages
> though is an issue.
>
> The fact that we can't get logging statements is a big issue. Filled
> a jira for this one (GERONIMO-3445).
>
I've modified logger config like:
#log4j.appender.CONSOLE.Threshold=${org.apache.geronimo.log.ConsoleLogLevel}
log4j.appender.CONSOLE.Threshold=INFO
and I've seen some more messages. There's no change in subject of
"OpenEJB jndi messages" but my problem primary problem was resolved.
Thank You for your help
Tomasz Mazan
Re: Is there any reason to use @Remote for session bean...
Posted by David Blevins <da...@visi.com>.
On Aug 27, 2007, at 2:30 AM, Tomasz Mazan wrote:
> David Blevins pisze:
>> In which case your ejbName is CustomerFacade not
>> CustomerFacadeImpl and you then get this:
>>
>> ejbName = CustomerFacade (set in @Stateless)
>> deploymentId = EJBtest-1.0.jar/CustomerFacade
>> jndiName = EJBtest-1.0.jar/CustomerFacade/
>> com.your.package.CustomerFacade
>>
>> I suspect this might be more accurate as you mentioned you found a
>> context when you looked up "EJBtest-1.0.jar/CustomerFacade" and
>> that would explain it.
> David, Thanks for your help. I've just finished "holidays" in this
> subject and start trying to finish resolving this problem.
Welcome back :)
> I'll must to investigate context using servlet to find all beans,
> because Your advice (EJBtest-1.0.jar/CustomerFacade(Impl)/
> com.your.package.CustomerFacade) hasn't helped me - I get
> NameNotFoundException :-(
Definitely give that a try. I wonder, does your bean class implement
the CustomerFacade remote interface? If not than maybe you don't
have any proxies at all -- we wouldn't have seen the interface. Just
kind of grabbing at straws :)
Looking forward to the output of the servlet.
>> As a last resort, you can change this line in server-
>> log4j.properties:
>> -log4j.rootLogger=ERROR, CONSOLE, FILE
>> +log4j.rootLogger=INFO, CONSOLE, FILE
>>
>> That should *definitely* do it, but the flood gates will be open :)
> Only one, additional item of "flood" is MEJBGBean exception:
>
> Module 6/36 org.apache.geronimo.configs/cxf/2.0-M6/
> car 11:14:45,906 WARN [startup] Unable to
> scrape for @Stateful, @
> Stateless or @MessageDriven annotations. EjbModule URL not valid:
> MEJBGBean
> java.net.MalformedURLException: no protocol: MEJBGBean
>
> ... and no messages about jndi. Strange
The MalformedURLException can safely be ignored, that's just a
message we need to clean up. The fact that we can't get the log
messages though is an issue.
The fact that we can't get logging statements is a big issue. Filled
a jira for this one (GERONIMO-3445).
-David
Re: Is there any reason to use @Remote for session bean...
Posted by Tomasz Mazan <wi...@wp.pl>.
David Blevins pisze:
>
> On Aug 20, 2007, at 1:40 PM, Tomasz Mazan wrote:
>
>> David Blevins pisze:
>>>>>> and try to get remote SB with method
>>>>>> this.ctx.lookup("EJBtest-1.0.jar/CustomerFacade");
>>>>>> and get instance of.... org.apache.openejb.client.JNDIContext..
>>>>>> where is my session bean?!
>>>>>
>>>>> I think you need to append the name of the interface you are
>>>>> trying to get. You could list the context to find out exactly
>>>>> what is bound there.
>>>> CustomerFacade is the name of my interface that i try to get and
>>>> when i try to list the context using JNDIContext.list method -
>>>> method throws exception javax.namin.OperationNotSupportedException:
>>>> TODO: Needs to be implemented
>>>
>>> Opened a JIRA for this (OPENEJB-668). It does work however on
>>> anything running in the server-side if they construct an initial
>>> context using org.apache.openejb.client.LocalInitialContextFactory
>>> as the JNDI inital context factory provider. You could do this in a
>>> servlet or ejb maybe. But before we go there, it sounds like
>>> CustomerFacade is the name of your bean implementation. That's the
>>> only way I can think that you would find a context there.
>>>
>>> Can you paste the bean class name and the remote interface name?
>> Class name : CustomerFacadeImpl (annotated with @Stateless)
>> Interface name : CustomerFacade (annotated with @Remote)
>
> Assuming the moduleId is 'EJBtest-1.0.jar' :
>
> ejbName = CustomerFacadeImpl (the default per spec rules)
> deploymentId = EJBtest-1.0.jar/CustomerFacadeImpl
> jndiName =
> EJBtest-1.0.jar/CustomerFacadeImpl/com.your.package.CustomerFacade
>
> Unless however you used the @Stateless annotation like this as I
> suspect you might have:
>
> @Stateless(name="CustomerFacade")
> public class CustomerFacadeImpl .... {..}
>
> In which case your ejbName is CustomerFacade not CustomerFacadeImpl
> and you then get this:
>
> ejbName = CustomerFacade (set in @Stateless)
> deploymentId = EJBtest-1.0.jar/CustomerFacade
> jndiName =
> EJBtest-1.0.jar/CustomerFacade/com.your.package.CustomerFacade
>
> I suspect this might be more accurate as you mentioned you found a
> context when you looked up "EJBtest-1.0.jar/CustomerFacade" and that
> would explain it.
David, Thanks for your help. I've just finished "holidays" in this
subject and start trying to finish resolving this problem.
I'll must to investigate context using servlet to find all beans,
because Your advice
(EJBtest-1.0.jar/CustomerFacade(Impl)/com.your.package.CustomerFacade)
hasn't helped me - I get NameNotFoundException :-(
>>>>>> There is CustomerFacade in JNDIViewer tree - Geronimo Console,
>>>>>> but....
>>>>>>
>>>>>> 2) Although I set key log4j.logger.OpenEJB.startup to value INFO,
>>>>>> there's no jndi messages on console
>>>
>>> Hmm. Did you get any additional output at all? Figuring out how to
>>> get those log messages is definitely our best bet. Maybe try just
>>> "log4j.logger.OpenEJB=INFO". Also check that a similar line isn't
>>> already there for any "OpenEJB" log cagetories.
>> There's no more messages than this about deploy of MEJBGBean
>> (warning). There's no jndi messages still there.
>
> As a last resort, you can change this line in server-log4j.properties:
> -log4j.rootLogger=ERROR, CONSOLE, FILE
> +log4j.rootLogger=INFO, CONSOLE, FILE
>
> That should *definitely* do it, but the flood gates will be open :)
Only one, additional item of "flood" is MEJBGBean exception:
Module 6/36
org.apache.geronimo.configs/cxf/2.0-M6/car
11:14:45,906 WARN [startup] Unable to scrape for @Stateful, @
Stateless or @MessageDriven annotations. EjbModule URL not valid: MEJBGBean
java.net.MalformedURLException: no protocol: MEJBGBean
... and no messages about jndi. Strange
Re: Is there any reason to use @Remote for session bean...
Posted by David Blevins <da...@visi.com>.
On Aug 20, 2007, at 1:40 PM, Tomasz Mazan wrote:
> David Blevins pisze:
>>>>> and try to get remote SB with method
>>>>> this.ctx.lookup("EJBtest-1.0.jar/CustomerFacade");
>>>>> and get instance of.... org.apache.openejb.client.JNDIContext..
>>>>> where is my session bean?!
>>>>
>>>> I think you need to append the name of the interface you are
>>>> trying to get. You could list the context to find out exactly
>>>> what is bound there.
>>> CustomerFacade is the name of my interface that i try to get and
>>> when i try to list the context using JNDIContext.list method -
>>> method throws exception
>>> javax.namin.OperationNotSupportedException: TODO: Needs to be
>>> implemented
>>
>> Opened a JIRA for this (OPENEJB-668). It does work however on
>> anything running in the server-side if they construct an initial
>> context using org.apache.openejb.client.LocalInitialContextFactory
>> as the JNDI inital context factory provider. You could do this in
>> a servlet or ejb maybe. But before we go there, it sounds like
>> CustomerFacade is the name of your bean implementation. That's
>> the only way I can think that you would find a context there.
>>
>> Can you paste the bean class name and the remote interface name?
> Class name : CustomerFacadeImpl (annotated with @Stateless)
> Interface name : CustomerFacade (annotated with @Remote)
Assuming the moduleId is 'EJBtest-1.0.jar' :
ejbName = CustomerFacadeImpl (the default per spec rules)
deploymentId = EJBtest-1.0.jar/CustomerFacadeImpl
jndiName = EJBtest-1.0.jar/CustomerFacadeImpl/
com.your.package.CustomerFacade
Unless however you used the @Stateless annotation like this as I
suspect you might have:
@Stateless(name="CustomerFacade")
public class CustomerFacadeImpl .... {..}
In which case your ejbName is CustomerFacade not CustomerFacadeImpl
and you then get this:
ejbName = CustomerFacade (set in @Stateless)
deploymentId = EJBtest-1.0.jar/CustomerFacade
jndiName = EJBtest-1.0.jar/CustomerFacade/
com.your.package.CustomerFacade
I suspect this might be more accurate as you mentioned you found a
context when you looked up "EJBtest-1.0.jar/CustomerFacade" and that
would explain it.
>>>>> There is CustomerFacade in JNDIViewer tree - Geronimo Console,
>>>>> but....
>>>>>
>>>>> 2) Although I set key log4j.logger.OpenEJB.startup to value
>>>>> INFO, there's no jndi messages on console
>>
>> Hmm. Did you get any additional output at all? Figuring out how
>> to get those log messages is definitely our best bet. Maybe try
>> just "log4j.logger.OpenEJB=INFO". Also check that a similar line
>> isn't already there for any "OpenEJB" log cagetories.
> There's no more messages than this about deploy of MEJBGBean
> (warning). There's no jndi messages still there.
As a last resort, you can change this line in server-log4j.properties:
-log4j.rootLogger=ERROR, CONSOLE, FILE
+log4j.rootLogger=INFO, CONSOLE, FILE
That should *definitely* do it, but the flood gates will be open :)
-David
Re: Is there any reason to use @Remote for session bean...
Posted by Tomasz Mazan <wi...@wp.pl>.
David Blevins pisze:
>>>> and try to get remote SB with method
>>>> this.ctx.lookup("EJBtest-1.0.jar/CustomerFacade");
>>>> and get instance of.... org.apache.openejb.client.JNDIContext..
>>>> where is my session bean?!
>>>
>>> I think you need to append the name of the interface you are trying
>>> to get. You could list the context to find out exactly what is
>>> bound there.
>> CustomerFacade is the name of my interface that i try to get and when
>> i try to list the context using JNDIContext.list method - method
>> throws exception javax.namin.OperationNotSupportedException: TODO:
>> Needs to be implemented
>
> Opened a JIRA for this (OPENEJB-668). It does work however on
> anything running in the server-side if they construct an initial
> context using org.apache.openejb.client.LocalInitialContextFactory as
> the JNDI inital context factory provider. You could do this in a
> servlet or ejb maybe. But before we go there, it sounds like
> CustomerFacade is the name of your bean implementation. That's the
> only way I can think that you would find a context there.
>
> Can you paste the bean class name and the remote interface name?
Class name : CustomerFacadeImpl (annotated with @Stateless)
Interface name : CustomerFacade (annotated with @Remote)
>>>> There is CustomerFacade in JNDIViewer tree - Geronimo Console, but....
>>>>
>>>> 2) Although I set key log4j.logger.OpenEJB.startup to value INFO,
>>>> there's no jndi messages on console
>
> Hmm. Did you get any additional output at all? Figuring out how to
> get those log messages is definitely our best bet. Maybe try just
> "log4j.logger.OpenEJB=INFO". Also check that a similar line isn't
> already there for any "OpenEJB" log cagetories.
There's no more messages than this about deploy of MEJBGBean (warning).
There's no jndi messages still there.
Tomasz Mazan
PS. Tommorow I'll try to list context with servlet or web service.
Re: Is there any reason to use @Remote for session bean...
Posted by David Blevins <da...@visi.com>.
On Aug 20, 2007, at 2:52 AM, Tomasz Mazan wrote:
>>> I've configured connection to context with theese settings
>>>
>>> Properties properties = new Properties();
>>> properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
>>> "org.apache.openejb.client.RemoteInitialContextFactory");
>>> properties.setProperty(Context.PROVIDER_URL, "ejbd://
>>> localhost:4201");
>>> this.ctx = new InitialContext(properties);
Great.
>>> and try to get remote SB with method
>>> this.ctx.lookup("EJBtest-1.0.jar/CustomerFacade");
>>> and get instance of.... org.apache.openejb.client.JNDIContext..
>>> where is my session bean?!
>>
>> I think you need to append the name of the interface you are
>> trying to get. You could list the context to find out exactly
>> what is bound there.
> CustomerFacade is the name of my interface that i try to get and
> when i try to list the context using JNDIContext.list method -
> method throws exception javax.namin.OperationNotSupportedException:
> TODO: Needs to be implemented
Opened a JIRA for this (OPENEJB-668). It does work however on
anything running in the server-side if they construct an initial
context using org.apache.openejb.client.LocalInitialContextFactory as
the JNDI inital context factory provider. You could do this in a
servlet or ejb maybe. But before we go there, it sounds like
CustomerFacade is the name of your bean implementation. That's the
only way I can think that you would find a context there.
Can you paste the bean class name and the remote interface name?
>>> There is CustomerFacade in JNDIViewer tree - Geronimo Console,
>>> but....
>>>
>>> 2) Although I set key log4j.logger.OpenEJB.startup to value INFO,
>>> there's no jndi messages on console
Hmm. Did you get any additional output at all? Figuring out how to
get those log messages is definitely our best bet. Maybe try just
"log4j.logger.OpenEJB=INFO". Also check that a similar line isn't
already there for any "OpenEJB" log cagetories.
-David
Re: Is there any reason to use @Remote for session bean...
Posted by Tomasz Mazan <wi...@wp.pl>.
David, thanks for your reply
>
> On Aug 20, 2007, at 2:12 AM, Tomasz Mazan wrote:
>
>> David Blevins pisze:
>>>
>>> On Aug 17, 2007, at 3:51 AM, Tomasz Mazan wrote:
>>>
>>>>
>>>> ..if there's no global jndi context and I can't get SBean within my
>>>> standalone java application client?
>>>> In addition - there's no chance to run old EJB2 application with
>>>> remote
>>>> client on Geronimo 2.0. May I'm wrong - so, please help me to
>>>> understand
>>>> this "feature".
>>>
>>> EJB 1.1, EJB 2.x and EJB 3.0 standalone clients do work.
>>>
>>> To connect to the server using the default settings:
>>>
>>> Properties props = new Properties();
>>> props.put("java.naming.factory.initial",
>>> "org.apache.openejb.client.RemoteInitialContextFactory");
>>> props.put("java.naming.provider.url", "foo://127.0.0.1:"
>>> + port);
>>> InitialContext context = new InitialContext(props);
>>>
>>> The JNDI Names for each bean are printed in INFO in the
>>> OpenEJB.startup log cagetory, which you can enable by adding this:
>>>
>>> log4j.logger.OpenEJB.startup=INFO
>>>
>>> ..to your var/log/server-log4j.properties file
>>>
>>> The output should look similar to the following:
>>>
>>> INFO - Assembling app:
>>> /Users/dblevins/work/openejb3/itests/openejb-itests-beans/target/classes
>>>
>>> INFO - Jndi(name=client/tests/entity/cmp/BasicCmpHome)
>>> INFO - Jndi(name=client/tests/entity/cmp/ComplexCmpHome)
>>> INFO - Jndi(name=client/tests/entity/cmp/UnknownCmpHome)
>>> INFO - Jndi(name=client/tests/entity/cmp2/BasicCmpHome)
>>> INFO - Jndi(name=client/tests/entity/cmp2/ComplexCmpHome)
>>> INFO - Jndi(name=client/tests/entity/cmp2/UnknownCmpHome)
>>> INFO - Jndi(name=client/tests/entity/cmp/allowed_operations/EntityHome)
>>> INFO -
>>> Jndi(name=client/tests/entity/cmp2/allowed_operations/EntityHome)
>>> INFO - Jndi(name=client/tests/entity/cmp/EncBean)
>>> INFO - Jndi(name=client/tests/entity/cmp2/EncBean)
>>> INFO - Jndi(name=client/tests/entity/cmp/ContextLookupCmpBean)
>>> INFO - Jndi(name=client/tests/entity/cmp/RMI-over-IIOP/EJBHome)
>>> INFO - Jndi(name=client/tests/entity/cmp2/RMI-over-IIOP/EJBHome)
>>> INFO - Jndi(name=client/tests/entity/cmr/oneToOne/PersonLocal)
>>> INFO - Jndi(name=client/tests/entity/cmr/oneToOne/LicenseLocal)
>>> INFO - Jndi(name=client/tests/entity/cmr/oneToMany/ArtistLocal)
>>> INFO - Jndi(name=client/tests/entity/cmr/oneToMany/SongLocal)
>>> INFO - Jndi(name=client/tests/entity/cmr/manyToMany/GameLocal)
>>>
>>> There is an open issue (GERONIMO-2884) regarding the default jndi
>>> names you may want to check out if you names like
>>> "geronimo-deploymentUtil5840.tmpdir/FooBeanBusinessRemote.
>>>
>>> Changing the format of the JNDI names is fine. The only drawback is
>>> offical javaee 5 application-client.xml style clients will no longer
>>> be able to look up ejbs (well, not using the java:comp/env snytax
>>> anyway, they could still look them up as standalone applications
>>> do). See the info on this page on how to reset the
>>> openejb.jndiname.format system variable:
>>>
>>> http://openejb.apache.org/jndi-names.html
>>>
>>> The default value is "{deploymentId}/{interfaceClass}"
>>>
>>> Hmmm... Looking at the code right now I see that its actually a bit
>>> tricky to set the "openejb.jndiname.format" property -- normally
>>> setting it as a system property would do the trick, but I see we're
>>> not checking to see if it was set before stuffing in the default.
>>>
>>> If you want to change the format, let me know and I will show you a
>>> couple options.
>>>
>>> -David
>> David, thank you for your response, and.... please help :-)
>>
>> I've configured connection to context with theese settings
>>
>> Properties properties = new Properties();
>> properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
>> "org.apache.openejb.client.RemoteInitialContextFactory");
>> properties.setProperty(Context.PROVIDER_URL,
>> "ejbd://localhost:4201");
>> this.ctx = new InitialContext(properties);
>>
>> and try to get remote SB with method
>> this.ctx.lookup("EJBtest-1.0.jar/CustomerFacade");
>> and get instance of.... org.apache.openejb.client.JNDIContext.. where
>> is my session bean?!
>
> I think you need to append the name of the interface you are trying to
> get. You could list the context to find out exactly what is bound there.
CustomerFacade is the name of my interface that i try to get and when i
try to list the context using JNDIContext.list method - method throws
exception javax.namin.OperationNotSupportedException: TODO: Needs to be
implemented
>>
>> There is CustomerFacade in JNDIViewer tree - Geronimo Console, but....
>>
>> 2) Although I set key log4j.logger.OpenEJB.startup to value INFO,
>> there's no jndi messages on console
>>
>> 3) May it be independent troublem, but I use persistence unit, with
>> properly configured (on server) connectio pool, and when I explore
>> (click) via jndi viewer, geronimo console prints error like
>> javax.naming.NotContextException:
>> geronimo/env/pl.netia.fonbsa.core.dao.facade.impl.CommonFacadeImpl/entityManager
>>
>> at
>> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:161)
>>
>> at
>> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611)
>>
>> at
>> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152)
>>
>> at
>> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597)
>>
>> at javax.naming.InitialContext.lookup(InitialContext.java:351)
>> at
>> org.apache.openejb.core.ivm.naming.JndiUrlReference.getObject(JndiUrlReference.java:34)
>>
>> This problem is common for my application and geronimo examples from
>> official site.
>
> entity managers are not bound to global jndi, so this is not
> surprising. Can your session bean get its entity manager?
I don't know yet, but I can't get my session bean. However, Geronimo's
examples works, so I suspect that it's beans use entity managers correctly.
Have you any solution for my "context" problem?
Tomasz Mazan
Re: Is there any reason to use @Remote for session bean...
Posted by David Jencks <da...@yahoo.com>.
On Aug 20, 2007, at 2:12 AM, Tomasz Mazan wrote:
> David Blevins pisze:
>>
>> On Aug 17, 2007, at 3:51 AM, Tomasz Mazan wrote:
>>
>>>
>>> ..if there's no global jndi context and I can't get SBean within my
>>> standalone java application client?
>>> In addition - there's no chance to run old EJB2 application with
>>> remote
>>> client on Geronimo 2.0. May I'm wrong - so, please help me to
>>> understand
>>> this "feature".
>>
>> EJB 1.1, EJB 2.x and EJB 3.0 standalone clients do work.
>>
>> To connect to the server using the default settings:
>>
>> Properties props = new Properties();
>> props.put("java.naming.factory.initial",
>> "org.apache.openejb.client.RemoteInitialContextFactory");
>> props.put("java.naming.provider.url", "foo://
>> 127.0.0.1:" + port);
>> InitialContext context = new InitialContext(props);
>>
>> The JNDI Names for each bean are printed in INFO in the
>> OpenEJB.startup log cagetory, which you can enable by adding this:
>>
>> log4j.logger.OpenEJB.startup=INFO
>>
>> ..to your var/log/server-log4j.properties file
>>
>> The output should look similar to the following:
>>
>> INFO - Assembling app: /Users/dblevins/work/openejb3/itests/
>> openejb-itests-beans/target/classes
>> INFO - Jndi(name=client/tests/entity/cmp/BasicCmpHome)
>> INFO - Jndi(name=client/tests/entity/cmp/ComplexCmpHome)
>> INFO - Jndi(name=client/tests/entity/cmp/UnknownCmpHome)
>> INFO - Jndi(name=client/tests/entity/cmp2/BasicCmpHome)
>> INFO - Jndi(name=client/tests/entity/cmp2/ComplexCmpHome)
>> INFO - Jndi(name=client/tests/entity/cmp2/UnknownCmpHome)
>> INFO - Jndi(name=client/tests/entity/cmp/allowed_operations/
>> EntityHome)
>> INFO - Jndi(name=client/tests/entity/cmp2/allowed_operations/
>> EntityHome)
>> INFO - Jndi(name=client/tests/entity/cmp/EncBean)
>> INFO - Jndi(name=client/tests/entity/cmp2/EncBean)
>> INFO - Jndi(name=client/tests/entity/cmp/ContextLookupCmpBean)
>> INFO - Jndi(name=client/tests/entity/cmp/RMI-over-IIOP/EJBHome)
>> INFO - Jndi(name=client/tests/entity/cmp2/RMI-over-IIOP/EJBHome)
>> INFO - Jndi(name=client/tests/entity/cmr/oneToOne/PersonLocal)
>> INFO - Jndi(name=client/tests/entity/cmr/oneToOne/LicenseLocal)
>> INFO - Jndi(name=client/tests/entity/cmr/oneToMany/ArtistLocal)
>> INFO - Jndi(name=client/tests/entity/cmr/oneToMany/SongLocal)
>> INFO - Jndi(name=client/tests/entity/cmr/manyToMany/GameLocal)
>>
>> There is an open issue (GERONIMO-2884) regarding the default jndi
>> names you may want to check out if you names like "geronimo-
>> deploymentUtil5840.tmpdir/FooBeanBusinessRemote.
>>
>> Changing the format of the JNDI names is fine. The only drawback
>> is offical javaee 5 application-client.xml style clients will no
>> longer be able to look up ejbs (well, not using the java:comp/env
>> snytax anyway, they could still look them up as standalone
>> applications do). See the info on this page on how to reset the
>> openejb.jndiname.format system variable:
>>
>> http://openejb.apache.org/jndi-names.html
>>
>> The default value is "{deploymentId}/{interfaceClass}"
>>
>> Hmmm... Looking at the code right now I see that its actually a
>> bit tricky to set the "openejb.jndiname.format" property --
>> normally setting it as a system property would do the trick, but I
>> see we're not checking to see if it was set before stuffing in the
>> default.
>>
>> If you want to change the format, let me know and I will show you
>> a couple options.
>>
>> -David
> David, thank you for your response, and.... please help :-)
>
> I've configured connection to context with theese settings
>
> Properties properties = new Properties();
> properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
> "org.apache.openejb.client.RemoteInitialContextFactory");
> properties.setProperty(Context.PROVIDER_URL, "ejbd://
> localhost:4201");
> this.ctx = new InitialContext(properties);
>
> and try to get remote SB with method
> this.ctx.lookup("EJBtest-1.0.jar/CustomerFacade");
> and get instance of.... org.apache.openejb.client.JNDIContext..
> where is my session bean?!
I think you need to append the name of the interface you are trying
to get. You could list the context to find out exactly what is bound
there.
>
> There is CustomerFacade in JNDIViewer tree - Geronimo Console, but....
>
> 1) when I deploy my application the console prints warn like:
> 10:45:38,906 WARN [Runtime] The property named
> "openjpa.ClassTransformerOptions" was not recognized and will be
> ignored, although the name
> closely matches a valid property called "openjpa.ClassResolver".
This is not a problem.
>
> 2) Although I set key log4j.logger.OpenEJB.startup to value INFO,
> there's no jndi messages on console
>
> 3) May it be independent troublem, but I use persistence unit, with
> properly configured (on server) connectio pool, and when I explore
> (click) via jndi viewer, geronimo console prints error like
> javax.naming.NotContextException: geronimo/env/
> pl.netia.fonbsa.core.dao.facade.impl.CommonFacadeImpl/entityManager
> at org.apache.xbean.naming.context.AbstractContext.lookup
> (AbstractContext.java:161)
> at org.apache.xbean.naming.context.AbstractContext.lookup
> (AbstractContext.java:611)
> at org.apache.xbean.naming.context.AbstractContext.lookup
> (AbstractContext.java:152)
> at org.apache.xbean.naming.context.AbstractContext.lookup
> (AbstractContext.java:597)
> at javax.naming.InitialContext.lookup(InitialContext.java:351)
> at
> org.apache.openejb.core.ivm.naming.JndiUrlReference.getObject
> (JndiUrlReference.java:34)
> This problem is common for my application and geronimo examples
> from official site.
entity managers are not bound to global jndi, so this is not
surprising. Can your session bean get its entity manager?
thanks
david jencks
>
> Please, help me to understand this strange behaviour.
>
> Tomasz Mazan
>
> PS. Let's changing jndi name format to near future.
Re: Is there any reason to use @Remote for session bean...
Posted by Tomasz Mazan <wi...@wp.pl>.
David Blevins pisze:
>
> On Aug 17, 2007, at 3:51 AM, Tomasz Mazan wrote:
>
>>
>> ..if there's no global jndi context and I can't get SBean within my
>> standalone java application client?
>> In addition - there's no chance to run old EJB2 application with remote
>> client on Geronimo 2.0. May I'm wrong - so, please help me to understand
>> this "feature".
>
> EJB 1.1, EJB 2.x and EJB 3.0 standalone clients do work.
>
> To connect to the server using the default settings:
>
> Properties props = new Properties();
> props.put("java.naming.factory.initial",
> "org.apache.openejb.client.RemoteInitialContextFactory");
> props.put("java.naming.provider.url", "foo://127.0.0.1:" +
> port);
> InitialContext context = new InitialContext(props);
>
> The JNDI Names for each bean are printed in INFO in the
> OpenEJB.startup log cagetory, which you can enable by adding this:
>
> log4j.logger.OpenEJB.startup=INFO
>
> ..to your var/log/server-log4j.properties file
>
> The output should look similar to the following:
>
> INFO - Assembling app:
> /Users/dblevins/work/openejb3/itests/openejb-itests-beans/target/classes
> INFO - Jndi(name=client/tests/entity/cmp/BasicCmpHome)
> INFO - Jndi(name=client/tests/entity/cmp/ComplexCmpHome)
> INFO - Jndi(name=client/tests/entity/cmp/UnknownCmpHome)
> INFO - Jndi(name=client/tests/entity/cmp2/BasicCmpHome)
> INFO - Jndi(name=client/tests/entity/cmp2/ComplexCmpHome)
> INFO - Jndi(name=client/tests/entity/cmp2/UnknownCmpHome)
> INFO - Jndi(name=client/tests/entity/cmp/allowed_operations/EntityHome)
> INFO - Jndi(name=client/tests/entity/cmp2/allowed_operations/EntityHome)
> INFO - Jndi(name=client/tests/entity/cmp/EncBean)
> INFO - Jndi(name=client/tests/entity/cmp2/EncBean)
> INFO - Jndi(name=client/tests/entity/cmp/ContextLookupCmpBean)
> INFO - Jndi(name=client/tests/entity/cmp/RMI-over-IIOP/EJBHome)
> INFO - Jndi(name=client/tests/entity/cmp2/RMI-over-IIOP/EJBHome)
> INFO - Jndi(name=client/tests/entity/cmr/oneToOne/PersonLocal)
> INFO - Jndi(name=client/tests/entity/cmr/oneToOne/LicenseLocal)
> INFO - Jndi(name=client/tests/entity/cmr/oneToMany/ArtistLocal)
> INFO - Jndi(name=client/tests/entity/cmr/oneToMany/SongLocal)
> INFO - Jndi(name=client/tests/entity/cmr/manyToMany/GameLocal)
>
> There is an open issue (GERONIMO-2884) regarding the default jndi
> names you may want to check out if you names like
> "geronimo-deploymentUtil5840.tmpdir/FooBeanBusinessRemote.
>
> Changing the format of the JNDI names is fine. The only drawback is
> offical javaee 5 application-client.xml style clients will no longer
> be able to look up ejbs (well, not using the java:comp/env snytax
> anyway, they could still look them up as standalone applications do).
> See the info on this page on how to reset the openejb.jndiname.format
> system variable:
>
> http://openejb.apache.org/jndi-names.html
>
> The default value is "{deploymentId}/{interfaceClass}"
>
> Hmmm... Looking at the code right now I see that its actually a bit
> tricky to set the "openejb.jndiname.format" property -- normally
> setting it as a system property would do the trick, but I see we're
> not checking to see if it was set before stuffing in the default.
>
> If you want to change the format, let me know and I will show you a
> couple options.
>
> -David
David, thank you for your response, and.... please help :-)
I've configured connection to context with theese settings
Properties properties = new Properties();
properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,
"org.apache.openejb.client.RemoteInitialContextFactory");
properties.setProperty(Context.PROVIDER_URL,
"ejbd://localhost:4201");
this.ctx = new InitialContext(properties);
and try to get remote SB with method
this.ctx.lookup("EJBtest-1.0.jar/CustomerFacade");
and get instance of.... org.apache.openejb.client.JNDIContext.. where is
my session bean?!
There is CustomerFacade in JNDIViewer tree - Geronimo Console, but....
1) when I deploy my application the console prints warn like:
10:45:38,906 WARN [Runtime] The property named
"openjpa.ClassTransformerOptions" was not recognized and will be
ignored, although the name
closely matches a valid property called "openjpa.ClassResolver".
2) Although I set key log4j.logger.OpenEJB.startup to value INFO,
there's no jndi messages on console
3) May it be independent troublem, but I use persistence unit, with
properly configured (on server) connectio pool, and when I explore
(click) via jndi viewer, geronimo console prints error like
javax.naming.NotContextException:
geronimo/env/pl.netia.fonbsa.core.dao.facade.impl.CommonFacadeImpl/entityManager
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:161)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:611)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:152)
at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:597)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at
org.apache.openejb.core.ivm.naming.JndiUrlReference.getObject(JndiUrlReference.java:34)
This problem is common for my application and geronimo examples from
official site.
Please, help me to understand this strange behaviour.
Tomasz Mazan
PS. Let's changing jndi name format to near future.
Re: Is there any reason to use @Remote for session bean...
Posted by David Blevins <da...@visi.com>.
On Aug 20, 2007, at 12:14 PM, David Blevins wrote:
>
> On Aug 18, 2007, at 4:34 PM, David Blevins wrote:
>
>> Hmmm... Looking at the code right now I see that its actually a
>> bit tricky to set the "openejb.jndiname.format" property --
>> normally setting it as a system property would do the trick, but I
>> see we're not checking to see if it was set before stuffing in the
>> default.
>
> FYI, also filed a JIRA for this one (GERONIMO-3423).
GERONIMO-3423 has been fixed in 2.1 trunk, will be porting this to
the 2.0 branch as well. I've also fixed the limitation that changing
the "openejb.jndiname.format" would break app client refs to ejbs.
Now you can change the "openejb.jndiname.format" and app client refs
to ejbs will still work.
-David
Re: Is there any reason to use @Remote for session bean...
Posted by David Blevins <da...@visi.com>.
On Aug 18, 2007, at 4:34 PM, David Blevins wrote:
> Hmmm... Looking at the code right now I see that its actually a bit
> tricky to set the "openejb.jndiname.format" property -- normally
> setting it as a system property would do the trick, but I see we're
> not checking to see if it was set before stuffing in the default.
FYI, also filed a JIRA for this one (GERONIMO-3423).
Re: Is there any reason to use @Remote for session bean...
Posted by David Blevins <da...@visi.com>.
On Aug 17, 2007, at 3:51 AM, Tomasz Mazan wrote:
>
> ..if there's no global jndi context and I can't get SBean within my
> standalone java application client?
> In addition - there's no chance to run old EJB2 application with
> remote
> client on Geronimo 2.0. May I'm wrong - so, please help me to
> understand
> this "feature".
EJB 1.1, EJB 2.x and EJB 3.0 standalone clients do work.
To connect to the server using the default settings:
Properties props = new Properties();
props.put("java.naming.factory.initial",
"org.apache.openejb.client.RemoteInitialContextFactory");
props.put("java.naming.provider.url", "foo://127.0.0.1:"
+ port);
InitialContext context = new InitialContext(props);
The JNDI Names for each bean are printed in INFO in the
OpenEJB.startup log cagetory, which you can enable by adding this:
log4j.logger.OpenEJB.startup=INFO
..to your var/log/server-log4j.properties file
The output should look similar to the following:
INFO - Assembling app: /Users/dblevins/work/openejb3/itests/openejb-
itests-beans/target/classes
INFO - Jndi(name=client/tests/entity/cmp/BasicCmpHome)
INFO - Jndi(name=client/tests/entity/cmp/ComplexCmpHome)
INFO - Jndi(name=client/tests/entity/cmp/UnknownCmpHome)
INFO - Jndi(name=client/tests/entity/cmp2/BasicCmpHome)
INFO - Jndi(name=client/tests/entity/cmp2/ComplexCmpHome)
INFO - Jndi(name=client/tests/entity/cmp2/UnknownCmpHome)
INFO - Jndi(name=client/tests/entity/cmp/allowed_operations/EntityHome)
INFO - Jndi(name=client/tests/entity/cmp2/allowed_operations/EntityHome)
INFO - Jndi(name=client/tests/entity/cmp/EncBean)
INFO - Jndi(name=client/tests/entity/cmp2/EncBean)
INFO - Jndi(name=client/tests/entity/cmp/ContextLookupCmpBean)
INFO - Jndi(name=client/tests/entity/cmp/RMI-over-IIOP/EJBHome)
INFO - Jndi(name=client/tests/entity/cmp2/RMI-over-IIOP/EJBHome)
INFO - Jndi(name=client/tests/entity/cmr/oneToOne/PersonLocal)
INFO - Jndi(name=client/tests/entity/cmr/oneToOne/LicenseLocal)
INFO - Jndi(name=client/tests/entity/cmr/oneToMany/ArtistLocal)
INFO - Jndi(name=client/tests/entity/cmr/oneToMany/SongLocal)
INFO - Jndi(name=client/tests/entity/cmr/manyToMany/GameLocal)
There is an open issue (GERONIMO-2884) regarding the default jndi
names you may want to check out if you names like "geronimo-
deploymentUtil5840.tmpdir/FooBeanBusinessRemote.
Changing the format of the JNDI names is fine. The only drawback is
offical javaee 5 application-client.xml style clients will no longer
be able to look up ejbs (well, not using the java:comp/env snytax
anyway, they could still look them up as standalone applications
do). See the info on this page on how to reset the
openejb.jndiname.format system variable:
http://openejb.apache.org/jndi-names.html
The default value is "{deploymentId}/{interfaceClass}"
Hmmm... Looking at the code right now I see that its actually a bit
tricky to set the "openejb.jndiname.format" property -- normally
setting it as a system property would do the trick, but I see we're
not checking to see if it was set before stuffing in the default.
If you want to change the format, let me know and I will show you a
couple options.
-David