[Remoting] - Re: ClassNotFoundException while calling remote ejb3 across
by avogt_sundn
let me explain my situation:
i'd like to have ejb behave polymorphic like with plain java classes. I know ONE interface of my ejbs but not ALL - and i don't need to know them all.
All my ejbs implement one common remote interface. I create ejb instances with a lookup and assign the ejb proxy to a variable typed with that know interface.
Now enters the org.jboss.ejb3.stateful.StatefulRemoteProxy that gets unmarshalled in my ear. That object references all the other remote interfaces of that ejb thus forcing a class loading of these interfaces - which is why i have to supply all these interfaces although i don't use them in code.
As you can see, I dont really want these interfaces to be downloaded anyway.
Its only for the sake of the StatefulRemoteProxy instance. There would be no need to download any classes remotely, because i have the known interface and the known parameter types included in each ear .
What breaks my architecture is the needs of the StatefulRemoteProxy.
Without this i cannot build a factory that is able to instantiate ejbs deployed in other isolated ears.
Perhaps there is some completely other way I cannot think of ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160453#4160453
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160453
17 years, 9 months
[Security & JAAS/JBoss] - Re: Validating login/password AND Client Certificate
by rameshsr
Here is what I did to solve the issue.
1. I extended org.jboss.security.auth.spi.BaseCertLoginModule and overriding the method getAliasAndCert() with my own implementation.
2. Use my extended LoginModule in place of BaseCertLoginModule in the login-config.xml file.
3. In the login-config.xml file use both the username/password authentication login module and the subclassed BaseCertLoginModule
4. In jboss-service.xml find the following entry
<mbean code="org.jboss.security.plugins.JaasSecurityManagerService"
In that change the values of the properties "DefaultCacheTimeout" and "DefaultCacheResolution" to zero. This is to disable the caching of security credentials, so that your certificate will be validated properly without caching.
I hope this will be helpful for anyone. If you need further details on my implementation of the getAliasAndCert() method, let me know. I will post the relevent portions of the code in the forum.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160436#4160436
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160436
17 years, 9 months
[JNDI/Naming/Network] - Re: How to Access EJB over HTTP in remote machine?
by robert.geisler
"ritesh163" wrote : * which container-name or section to change to what in conf/standardjboss.xml.
it depends on your EJBs. for Stateless SessionBeans for example JBoss defaults to "Standard Stateless SessionBean" if not another container-configuration is declared in the deployment descriptor of your EJBs. every container-configuration uses a invoker-proxy-binding-name to refer to its invoker, "stateless-unified-invoker" is the default for the "Standard Stateless SessionBean" configuration.
we added a new invoker called "stateless-http-invoker" (see below) and a new container-configuration "Custom Stateless SessionBean" referring to the new invoker. in the deployment descriptors of our EJBs we configured the new container-configuration.
standardjboss.xml:
| <jboss>
| <container-configurations>
| ...
| <!-- extend default container-configuration, use different invoker --> <container-configuration extends="Standard Stateless SessionBean"> <container-name>Custom Stateless SessionBean</container-name> <invoker-proxy-binding-name>stateless-http-invoker</invoker-proxy-binding-name> </container-configuration>
| </container-configurations>
| ...
| <invoker-proxy-bindings>
| <!-- copy standard-unified-invoker, change type to http -->
| <invoker-proxy-binding> <name>stateful-http-invoker</name>
| <invoker-mbean>jboss:service=invoker,type=http</invoker-mbean> ...
| </invoker-proxy-binding>
| </invoker-proxy-bindings>
| ...
| </jboss>
jboss.xml (deployment deskriptor):
| <jboss>
| <enterprise-beans>
| <session>
| <ejb-name>MyStatelessSessionBean</ejb-name>
| ... <configuration-name>Custom Stateless SessionBean</configuration-name> ...
| </session>
| ...
| </enterprise-beans>
| ...
| </jboss>
"ritesh163" wrote : * if external addresses are set as the InvokerURLs for the servlets then will I have to set external IP at start of server. I am using below command to start the server: run.sh -c default -b [internal ip] for Jboss. If I replace [internal ip] with [external ip] then the server won't start.
start option "-b" tells JBoss to which address to bind to, so your internal ip should be the correct parameter. just for the InvokerURLs of the servlets you have to set the external ip, because JBoss sends the InvokerURL back to the clients to let them know where to connect to. nonetheless you have to know the external ip on start of JBoss, because you cannot change the InvokerURL on runtime. if you do not know the external ip, then there is a little trick: instead of an address you can set a simple String for the InvokerURL, "jboss.ejb2.invoker.http" for example. JBoss will interpret this String as a key for a system property (on the client machine). the value of the system property can be set by your client application to set the InvokerURL on runtime.
we use this trick and set the InvokerURL in the client, because JBoss does not know the address where clients have to connect to. in our client application we just try to connect to the external ip. if the external ip is available we set it as the value of the system property; if it is not available we set the internal ip. doing it this way our client is able to connect to JBoss from LAN (internal address) and over the internet (external address).
"ritesh163" wrote : * Also can I use domain name in place of IPs?
because you can set system property names as InvokerURLs i would guess domain names are supported, too. but i did not test this. just give it a try.
kind regards
robert
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4160435#4160435
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4160435
17 years, 9 months