[EJB/JBoss] - Accessing serialized timer objects
by Renen
Hello,
I hope that this is the right forum and apologise if it isn't.
I would like to be able to produce a friendly list of timers. In other words, the list should reflect something along the following lines:
* 15 Dec 2009, 3:52PM: Launch space rocket 12 (za.co.acme.messages.TestMessage@31491f7b)
* 23 Dec 2009, 11:00AM: Sell Mr Smiths shares and reap vast profits (za.co.acme.messages.TestMessage@e2df60d)
Displaying the time is trivial.
However, I am not clear how I can interrogate the objects that have been serialised into the database - the objects returned by getTimers() are reluctant to be de-serialized and horrible errors are thrown when you try (I suspect because they probably aren't read from the database until the events actually fire).
In our scenario, everything we are serializing into the timer system implements a consistent interface: "Description" which allows us to retrieve the details we require.
Is there a way to retrieve the objects so that I can interrogate them? Or to store additional information with the timer? Obviously, I would prefer not to maintain an additional data store.
I currently retrieve the timers using getTimers(), and I then iterate over the collection calling getInfo() on each Timer.
I am running JBoss 5.1.0.GA.
Thank you in advance for your guidance.
Renen.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249942#4249942
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249942
16 years, 10 months
[EJB 3.0] - persistence-context-ref always yields same object instance i
by henk53
Hi,
I'm experimenting a little with the different ways of programmatically obtaining an entity manager inside a servlet. I'm running Jboss 5.10 on Mac OS X 10.5.7 using JDK 6.
I tried the approach of using a persistence-context-ref element in web.xml, basically as outlined here: http://weblogs.java.net/blog/ss141213/archive/2005/12/dont_use_persis_1.html
My reference looks like this:
| <persistence-context-ref>
| <persistence-context-ref-name>persistence/test</persistence-context-ref-name>
| <persistence-unit-name>testpu</persistence-unit-name>
| </persistence-context-ref>
|
By itself this seems to work beautifully for doing JNDI lookups in a Servlet or Filter:
| EntityManager entityManager = (EntityManager )new InitialContext().lookup("java:comp/env/persistence/test");
|
The above code snippet gives me back an instance of the entity manager. However, I discovered with a debugger that this is always the same instance. Whether I do the JNDI lookup multiple times right after each other in the same method, or test what the JNDI lookup returns in multiple simultaneous requests, the result is always an object instance with the same ID (e.g. org.jboss.jpa.tx.TransactionScopedEntityManager@d78f1b).
When I however bind the entity manager factory into the global JNDI name space using the following property in persistence.xml:
| <property name="jboss.entity.manager.factory.jndi.name" value="java:/test_pu_factory"/>
|
And lookup that factory using JNDI again and then use that to create an entity manager, the instance is always different.
As per the advice that an entity manager is not tread-safe (and thus should not be stored in an instance variable of a servlet), I wonder whether it's correct that the JNDI lookup for the entity manager bound via the persistence-context-ref element always returns the same object instance.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249938#4249938
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249938
16 years, 10 months
[Security & JAAS/JBoss] - Basic HTTP authentication for WSDL (using JAAS LoginModule)
by TimStorms
Hi,
I'm trying to use basic HTTP authentication for my WSDL. The user credentials should be validated by a (JAAS) LoginModule for Atlassian Crowd. Somehow the deployment of my EAR file fails. The following stacktrace shows up in my logs:
| java.lang.NullPointerException
| at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorFactory.createPerClass(RoleBasedAuthorizationInterceptorFactory.java:49)
| at org.jboss.aop.advice.AspectFactoryDelegator.createPerClass(AspectFactoryDelegator.java:107)
| at org.jboss.aop.Advisor.addPerClassAspect(Advisor.java:569)
| at org.jboss.aop.advice.ScopedInterceptorFactory.create(ScopedInterceptorFactory.java:72)
| at org.jboss.aop.Advisor.createInterceptorChain(Advisor.java:618)
| at org.jboss.aop.Advisor.pointcutResolved(Advisor.java:888)
| at org.jboss.aop.Advisor.resolveMethodPointcut(Advisor.java:650)
| at org.jboss.aop.ClassContainer.createInterceptorChains(ClassContainer.java:248)
| at org.jboss.aop.ClassContainer.rebuildInterceptors(ClassContainer.java:115)
| at org.jboss.aop.ClassContainer.initializeClassContainer(ClassContainer.java:58)
| at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:342)
| at org.jboss.ejb3.SessionContainer.processMetadata(SessionContainer.java:140)
| at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:292)
| at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:356)
| at org.jboss.ejb3.Ejb3Module.startService(Ejb3Module.java:91)
| 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(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| 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)
|
Apparantly the RoleBasedAuthorizationInterceptorFactory throws an exception on line 49. When I checked its source, I've found the following code:
ctx.lookup("java:/jaas/" + securityAnnotation.value());
Probably, this means that the class doesn't find my SecurityDomain annotation, while it IS present. I've got the following annotations on my web service:
| @Stateless
| @SecurityDomain("mydomain")
| @SOAPBinding(style = SOAPBinding.Style.RPC, use = SOAPBinding.Use.LITERAL)
| @WebService(name = "ProjectWebService", targetNamespace = "url", serviceName = "service")
| @WebContext(urlPattern = "/url", authMethod ="BASIC", transportGuarantee ="NONE", secureWSDLAccess = false)
| @RolesAllowed("admin")
| @Remote(clazz.class)
|
Other things I've done:
web.xml:
| <security-constraint>
| <web-resource-collection>
| <web-resource-name>wsdl</web-resource-name>
| <url-pattern>/url</url-pattern>
| </web-resource-collection>
| <auth-constraint>
| <role-name>admin</role-name>
| </auth-constraint>
| </security-constraint>
| <login-config>
| <auth-method>BASIC</auth-method>
| </login-config>
| <security-role>
| <role-name>admin</role-name>
| </security-role>
|
login-config.xml (in the conf folder):
| <application-policy name="mydomain">
| <authentication>
| <login-module code="com.atlassian.crowd.application.jaas.CrowdLoginModule" flag = "required">
| <module-option name="application.name">admin</module-option>
| <module-option name="application.password">admin</module-option>
| <module-option name="crowd.server.url">server/</module-option>
| </login-module>
| </authentication>
| </application-policy>
|
This is the code which should be responsible for authenticating the users. What am I doing wrong here? Thanks!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4249936#4249936
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4249936
16 years, 10 months