[jboss-user] [Management, JMX/JBoss] - Re: Can not load MBeanServerBuilderImpl
I have the same problem under fedora 9 and JBoss developer studio 1.1 with its included JBoss as anonymous wrote : [Server] Release ID: JBoss [EAP] 4.3.0.GA_CP01 (build: SVNTag=JBPAPP_4_3_0_GA_CP01 date=200804211657) : I was runnung all under windows and everything was fine, now I installed a linux fedora 9 to be nearer to the deployement envirenment, everything is configured correctly but this error raises on server startup (under eclipse). | 09:41:34,357 INFO [DerbyDatabase] starting derby jdbc:derby:/home/zied/Programs/JBoss/jboss-eap/jboss-as/server/default/data/derby/default;create=true | 09:41:34,771 WARN [ServiceController] Problem starting service jboss:service=Derby | java.lang.ExceptionInInitializerError | at java.lang.Class.forName0(Native Method) | at java.lang.Class.forName(Class.java:264) | at org.jboss.jdbc.DerbyDatabase.getConnection(DerbyDatabase.java:222) | at org.jboss.jdbc.DerbyDatabase.startService(DerbyDatabase.java:189) | at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) | at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) | at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) | at java.lang.reflect.Method.invoke(Method.java:616) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) | at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) | at $Proxy0.start(Unknown Source) | at org.jboss.system.ServiceController.start(ServiceController.java:417) | at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) | at java.lang.reflect.Method.invoke(Method.java:616) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) | at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) | at $Proxy4.start(Unknown Source) | at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) | at java.lang.reflect.Method.invoke(Method.java:616) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) | at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) | at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) | at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) | at $Proxy42.start(Unknown Source) | at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197) | at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) | at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) | at java.lang.reflect.Method.invoke(Method.java:616) | | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) | at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) | at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) | at org.jboss.mx
[jboss-user] [JBoss Seam] - Re: roles redirecting methods
Hi Shane, Maybe I should enumerate the benefits I see in this approach: | +Suppress redundant (and error prone) information when you redirect programatically to a rule specific method (that you also enforse with a @Restricted with the "already tested" rule) | +Modeling tools will be able to reverse engineer "per rule" sequence diagrams | +Builders can remove all non relevant methods in a given subproduct configuration | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122511#4122511 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122511 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: roles redirecting methods
Hi Shane,
Sorry if my last mail wasn't clear. I'll explain the idea by the mean of a
frequent example:
Let's imagine we have an application with 3 rules: client, commercial and
administrator : the client can see only its orders, the commercial can only see
the orders of his clients and the administrator can see all orders:
This example can only be developed like this :
| doCommonCode();
| if( rule="commercial" ) {
| doCommercial();
| } else if( rule="client" ) {
| doClient();
| } else if( rule="administrator" ) {
| doAdministrator();
| }
The new seam authorization mecanism cant' do this simply beacuse the
@Restricted annotation is binary (not a switch). These if else blocks become
very frequent and reduce code readability.
The solution I sent is just a proposition: It attempts to add to the
annotations the responsibility to redirect to the business rule case method.
Here's how I imagine it:
@RuleSensible comes as the @Override annotation : it just enforces readability
and code changes safety : it informs this method is a rule switch. (inside the
method body comes the common code to all cases)
@RuleCase( method="switchMethodName ) is there to say : this is a switch case
for the given method
and finally @Restricted comes to say which rule case must be handled by the
annotated method.
So here was my idea, I hope you'll like it.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4121738#4121738
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4121738
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - roles redirecting methods
Hi,
I'm learning Seam and its role extended features. It's a very big step compared
to JAAS but I recognize I expected a more adapted behavior :-/
In fact, the code is always full of test cases that redirect to the
corresponding method for a given role if( "role1" ) doThis(); else doThat(); to
return a restricted result list or simply overdrive a deature againt the role.
I was suprised Seam didn't adress this common concept, even more because I was
very pleased by the other aspects of Seam, espacially conversations.
The idea I imagined to solve code repetition for role testing was sth like an
intercepted method :
@RoleSensible
| void myMethod() { //do common tasks };
then intercepting methods e.g:
| @RoleCase( method="myMethod" )
| @Restricted("#{s:hasPermission('bean', 'case1', user)}")
| void case1() {};
|
the annotation I imagined @RoleSensible should be mandatory, even it's just
there only to warn the method will be intercepted.
Do I have to add a feature request? or maybe is it not in the spirit Seam was
designed in?
Regards,
Zied hamdi
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4120032#4120032
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4120032
___
jboss-user mailing list
jboss-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JNDI/Naming/Network] - Re: EJB not visible through JNDI
Hi, The problem was due to a rhstudio bug (I think), I resolved it by creating a new EJB3 project and appending it to the existing ear. (When I use the new project wizard for an ear, ejb 3 is not proposed. Even if I change the xml files after that to be JEE 5, there's something (I don't know what) that goes wrong... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080903#4080903 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080903 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JNDI/Naming/Network] - EJB not visible through JNDI
Hi, I'm experiencing a strange problem: I can see my EJB3 bean under the web console under the the path: System/JMX MBeans/jboss.j2ee/jboss.j2ee:jar=MyEjbJar.jar... it is clearely recognized as a Stateless EJB: MBean Name: Domain Name:jboss.j2ee | service:EJB3 | name: ViewPersonListCommand | jar:IntoServicesEJB.jar | MBean Java Class: org.jboss.ejb3.stateless.StatelessDelegateWrapper But my lookup to the name: ViewPersonListCommand/local throws a naming exception: Caused by: java.lang.RuntimeException: Can't find Bean under JNDI: 'ViewPersonListCommand/local' | at fr.into.common.ejb.EJBUtil.lookup(EJBUtil.java:15) | at fr.into.services.controller.session.User.(User.java:22) | at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) | at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) | at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) | at java.lang.reflect.Constructor.newInstance(Constructor.java:513) | at java.lang.Class.newInstance0(Class.java:355) | at java.lang.Class.newInstance(Class.java:308) | at com.sun.faces.config.ManagedBeanFactoryImpl.newInstance(ManagedBeanFactoryImpl.java:277) | ... 93 more | Caused by: javax.naming.NameNotFoundException: ViewPersonListCommand not bound | at org.jnp.server.NamingServer.getBinding(NamingServer.java:529) | at org.jnp.server.NamingServer.getBinding(NamingServer.java:537) | at org.jnp.server.NamingServer.getObject(NamingServer.java:543) | at org.jnp.server.NamingServer.lookup(NamingServer.java:267) | at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627) | at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:589) | at javax.naming.InitialContext.lookup(InitialContext.java:392) | at fr.into.common.ejb.EJBUtil.lookup(EJBUtil.java:13) Does anyone have any idea? Thanks a lot, this is taking me a lot of time and there's no way to see which JNDI name is mapped to the bean. In addition to that, the same name worked until I've tryed to add Facelet capabilities to my app. I know this doesn't have anything to do with it but it's what I'm experiencing today. Naturally there's no message saying that the bean wasn't deployed or any problem occured while deploying the EJB jar... Thanks, View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080854#4080854 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080854 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [EJB 3.0] - Re: Backing beans
Hi Raskri, Your post was really useful for me, I found it as the second link in my first googling attemp (jboss "backing beans" admin) ;-). I'd like to know why JBoss doesn't supply a richer admin interface: there's no way to see which JNDI path was applied to a resource, I still didn't find where to look in the jmx or web console to see the deployed Backing beans, there's a node for the war but (it shows only the servlets) no node for the ejb jars... The onfo is really exploded :-/ Does someone maybe know about another "independent" admin console developed to fill these blanks?... Regards, Zied Hamdi View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4078659#4078659 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4078659 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
