October 2007 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Integration on JBoss5: NullPointerException deploying jm

by clebert.suconic＠jboss.com

The null pointer exception is gone, but whenever I deploy a MDB on trunk I get this error now. 12:01:04,027 ERROR [AbstractKernelController] Error installing to Start: name=jboss.j2ee:binding=message-driven-bean,jndiName=local/MDBExample@6173902,plugin=invoker,service=EJB state=Create mode=Manual requiredState=Installed | org.jboss.deployment.DeploymentException: Required config property RequiredConfigPropertyMetaData@718e31[name=destination descriptions=[DescriptionMetaData@13864d9[language=en]]] for messagingType 'javax.jms.MessageListener' not found in activation config [ActivationConfigProperty(maxMessages=1), ActivationConfigProperty(DLQMaxResent=10), ActivationConfigProperty(DLQJNDIName=queue/DLQ), ActivationConfigProperty(useDLQ=true), ActivationConfigProperty(keepAlive=30000), ActivationConfigProperty(providerAdapterJNDI=DefaultJMSProvider), ActivationConfigProperty(maxSession=15), ActivationConfigProperty(minSession=1)] ra=jboss.jca:service=RARDeployment,name='jms-ra.rar' | at org.jboss.resource.deployment.ActivationSpecFactory.createActivationSpec(ActivationSpecFactory.java:95) | at org.jboss.resource.deployers.RARDeployment.createActivationSpec(RARDeployment.java:312) | at org.jboss.resource.deployers.RARDeployment.internalInvoke(RARDeployment.java:276) | at org.jboss.system.ServiceDynamicMBeanSupport.invoke(ServiceDynamicMBeanSupport.java:156) | at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) | at org.jboss.ejb.plugins.inflow.JBossMessageEndpointFactory.createActivationSpec(JBossMessageEndpointFactory.java:448) | at org.jboss.ejb.plugins.inflow.JBossMessageEndpointFactory.startService(JBossMessageEndpointFactory.java:197) | at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:299) | at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) | at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) | 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:668) | at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:167) | at $Proxy4.start(Unknown Source) | at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42) | at org.jboss.system.microcontainer.ServiceControllerContextAction.install(ServiceControllerContextAction.java:46) | at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) | at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327) | at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:239) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1309) | at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411) | at org.jboss.system.ServiceController.doChange(ServiceController.java:659) | at org.jboss.system.ServiceController.start(ServiceController.java:431) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) | 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:668) | at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:194) | at org.jboss.ejb.MessageDrivenContainer.startService(MessageDrivenContainer.java:273) | at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:299) | at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) | at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) | 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:668) | at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:167) | at $Proxy4.start(Unknown Source) | at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42) | at org.jboss.system.microcontainer.ServiceControllerContextAction.install(ServiceControllerContextAction.java:46) | at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) | at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327) | at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:239) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1309) | at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411) | at org.jboss.system.ServiceController.doChange(ServiceController.java:659) | at org.jboss.system.ServiceController.start(ServiceController.java:431) | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) | 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:668) | at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) | at $Proxy62.start(Unknown Source) | at org.jboss.ejb.EjbModule.startService(EjbModule.java:477) | at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:299) | at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) | at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) | 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:668) | at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:167) | at $Proxy4.start(Unknown Source) | at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42) | at org.jboss.system.microcontainer.ServiceControllerContextAction.install(ServiceControllerContextAction.java:46) | at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) | at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327) | at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:239) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1309) | at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411) | at org.jboss.system.ServiceController.doChange(ServiceController.java:659) | at org.jboss.system.ServiceController.start(ServiceController.java:431) | at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:149) | at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:107) | at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46) | at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:65) | at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:169) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:728) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:749) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:781) | at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:669) | at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:327) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1309) | at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:734) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:862) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:784) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:622) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:411) | at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:495) | at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:354) | at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:290) | at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:221) | at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) | at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280) | at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135) | at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65) | at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142) | at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166) | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) | at java.lang.Thread.run(Thread.java:595) | 12:01:04,044 WARN [HDScanner] Failed to process changes | org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS): | | *** CONTEXTS IN ERROR: Name -> Error | | jboss.j2ee:binding=message-driven-bean,jndiName=local/MDBExample@6173902,plugin=invoker,service=EJB -> org.jboss.deployment.DeploymentException: Required config property RequiredConfigPropertyMetaData@718e31[name=destination descriptions=[DescriptionMetaData@13864d9[language=en]]] for messagingType 'javax.jms.MessageListener' not found in activation config [ActivationConfigProperty(maxMessages=1), ActivationConfigProperty(DLQMaxResent=10), ActivationConfigProperty(DLQJNDIName=queue/DLQ), ActivationConfigProperty(useDLQ=true), ActivationConfigProperty(keepAlive=30000), ActivationConfigProperty(providerAdapterJNDI=DefaultJMSProvider), ActivationConfigProperty(maxSession=15), ActivationConfigProperty(minSession=1)] ra=jboss.jca:service=RARDeployment,name='jms-ra.rar' | | | at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:620) | at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:393) | at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:291) | at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:221) | at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) | at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280) | at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135) | at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65) | at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142) | at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166) | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) | at java.lang.Thread.run(Thread.java:595) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096199#4096199 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096199

18 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Node removal not working with Invalidation?

by bstansberry＠jboss.com

Drat; there's a serious problem here when the removed node has children: http://jira.jboss.com/jira/browse/JBCACHE-1200 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096188#4096188 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096188

18 years, 5 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Generate SSOID in WebAuthentication

by cristant＠fstrf.org

OK, that makes sense. How long is it usually between the point releases like 4.2.1 to 4.2.2? Just trying to get a sense as to whether 4.2.3 will be out before we need to have this issue resolved since I can probably work around it. Thanks, ~Matt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096185#4096185 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096185

18 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Node removal not working with Invalidation?

by bstansberry＠jboss.com

Test is committed; minor JIRA to improve it is http://jira.jboss.com/jira/browse/JBCACHE-1199 . This is a bit conceptually murky though, since the removeNode call actually removes the node on the cache where the call was made, but leaves it around on remote nodes. For example, a unit test that passes would look like this (assume the isValid() bit works): | assertEquals(true, cache1.removeNode(fqn)); | | // Node should actually be gone locally | assertFalse(root1.hasChild(fqn)); | | // Node should still exist but be "invalid" on remote caches | Node remoteNode = root2.getChild(fqn); | assertNotNull(remoteNode); | assertFalse(remoteNode.isValid()); | | assertEquals(false, cache1.removeNode(fqn)); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096159#4096159 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096159

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Instance annotations from Object Models

by bill.burke＠jboss.com

* I don't see how something like the EJB3 container could use any of this. * The AOP examples you give are all driven off of class level annotations. Where are the method/field driven ones? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096120#4096120 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096120

18 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: So what does unification mean for the ejb containers

by wolfc

I can't make the jboss_5_0.xsd, namespace restrictions and model fit together. The spec xsds don't expose any elements, so the only way to use an element in another namespace is by using a ref on a group or by extension. This leads to very weird constructs:<?xml version="1.0"?> | <jboss | xmlns="http://www.jboss.com/xml/ns/javaee" | xmlns:jee="http://java.sun.com/xml/ns/javaee" | xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" | xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee | http://www.jboss.org/j2ee/schema/jboss_5_0.xsd" | version="3.0"> | <enterprise-beans> | <service> | <ejb-name>ServiceSix</ejb-name> | <ejb-class>org.jboss.ejb3.test.service.ServiceSix</ejb-class> | <object-name>object name</object-name> | <local>org.jboss.ejb3.test.service.ServiceSixLocal</local> | <remote>org.jboss.ejb3.test.service.ServiceSixRemote</remote> | <management>org.jboss.ejb3.test.service.ServiceSixManagement</management> | <xmbean>xmbean</xmbean> | <remote-binding> | <client-bind-url>client bind url</client-bind-url> | </remote-binding> | <jndi-name>serviceSix/remote</jndi-name> | <local-jndi-name>serviceSix/local</local-jndi-name> | <ejb-ref> | <ejb-ref-name>ejb/StatelessBean</ejb-ref-name> | <ejb-ref-type>Session</ejb-ref-type> | <remote>org.jboss.ejb3.test.service.StatelessRemote</remote> | <ejb-link>StatelessBean</ejb-link> | <jee:injection-target> | <jee:injection-target-class>org.jboss.ejb3.test.service.ServiceSix</jee:injection-target-class> | <jee:injection-target-name>stateless</jee:injection-target-name> | </jee:injection-target> | <jndi-name>StatelessBean/remote</jndi-name> | </ejb-ref> | <ejb-local-ref> | <ejb-ref-name>ejb/StatelessLocal</ejb-ref-name> | <ejb-ref-type>Session</ejb-ref-type> | <local>org.jboss.ejb3.test.service.StatelessLocal</local> | <ejb-link>StatelessBean</ejb-link> | <jee:injection-target> | <jee:injection-target-class>org.jboss.ejb3.test.service.ServiceSix</jee:injection-target-class> | <jee:injection-target-name>setStatelessLocal</jee:injection-target-name> | </jee:injection-target> | <jndi-name>StatelessBean/local</jndi-name> | </ejb-local-ref> | <security-identity> | <jee:run-as> | <jee:role-name>role name</jee:role-name> | </jee:run-as> |  | </security-identity> | <resource-ref> | <res-ref-name>testDatasource</res-ref-name> | <res-type>javax.sql.DataSource</res-type> | <res-auth>Container</res-auth> | <res-sharing-scope>Shareable</res-sharing-scope> | <mapped-name>java:/DefaultDS</mapped-name> | <jee:injection-target> | <jee:injection-target-class>org.jboss.ejb3.test.service.ServiceSix</jee:injection-target-class> | <jee:injection-target-name>testDatasource</jee:injection-target-name> | </jee:injection-target> | </resource-ref> | <resource-env-ref> | <jee:description>A test of the resource-env-ref tag</jee:description> | <jee:resource-env-ref-name>res/aQueue</jee:resource-env-ref-name> | <jee:resource-env-ref-type>javax.jms.Queue</jee:resource-env-ref-type> | <jndi-name>queue/mdbtest</jndi-name> | </resource-env-ref> | <message-destination-ref> | <message-destination-ref-name>messageDestinationRef</message-destination-ref-name> | <jee:mapped-name>mappedName</jee:mapped-name> | </message-destination-ref> | <security-domain>security domain</security-domain> | <method-attributes> | <method> | <method-name>test</method-name> | <transaction-timeout>1</transaction-timeout> | </method> | </method-attributes> | </service> | </enterprise-beans> | </jboss> | All elements directly under service are in jboss namespace, I could make an extension on session-beanType, but that would throw the model into a fit. ejb-ref and ejb-local-ref are pretty consistent. security-identity somehow defies the xsd I've defined for it, but fits the model. Then wickedness ensues: resource-ref can't be an extension, because it redefines the usage of mapped-name. It should however be an extension (as resource-env-ref) because now description won't fit the model. It leads to a mapped-name from a different namespace as shown in message-destination-ref. And thus I can't fit both of them into one unified model. So currently I'm at a stalemate. Any suggestions? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096105#4096105 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096105

18 years, 5 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Generate SSOID in WebAuthentication

by anil.saldhana＠jboss.com

"cristant(a)fstrf.org" wrote : I've been tracking this issue for a couple weeks now, since having SSO int he programmatic web login classes would make the facility I wrote to pass user authentication over from a legacy portal application a lot easier. | | Obviously I can implement something like CAS instead, but what we have now will work perfectly as long as the SSO tokens get set. | | Thanks, | ~Matt Matt, this issue is still in the back of my mind. So it is not dead yet. It will not make into the 4.2.2 release (as that is coming out soon). But will be part of 4.2.3 I guess. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096104#4096104 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096104

18 years, 5 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Generate SSOID in WebAuthentication

by cristant＠fstrf.org

I've been tracking this issue for a couple weeks now, since having SSO int he programmatic web login classes would make the facility I wrote to pass user authentication over from a legacy portal application a lot easier. Obviously I can implement something like CAS instead, but what we have now will work perfectly as long as the SSO tokens get set. Thanks, ~Matt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096085#4096085 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096085

18 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Node removal not working with Invalidation?

by bstansberry＠jboss.com

Ah, yes. That makes sense. I didn't check the test in yet; wanted to post here first and see if I was conceptually off base -- which it seems I was. :-) I'll change the test along the lines you suggest and commit it. Seems Node.isValid() won't work yet; it always returns true with a TODO to implement it. I'll add a minor JIRA to fix the test once isValid() is implemented. I wrote a similar test with pessimistic locking and it passed fine. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096080#4096080 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096080

18 years, 5 months

1
0
0 / 0

[Design of JBoss jBPM] - Extending the GPD with external plugins

by msandoz

I've submitted a comment/attachment for http://jira.jboss.com/jira/browse/GPD-143 that addresses where the palette root gets its icons but there's another few issues involved with getting a fully separate plugin to work on top of the designer. I believe this also relates to GPD-173. I've done some recent work in this area and the issues I have not resolved in an elegant manner are these: How should we determine the ordering of the palette groups? My solution was to hard code the order of palette addition in the paletteroot as: basic tools, tools from other plugins, advanced tools, transition tools. This was ugly. A category ranking could resolve that issue. How should we determine property tab group order? When property categories are loaded from different plugins, ordering is problematic. It is much the same issue as #1. above. Could a category ranking be the best way? This one I got around by including my category in the GPD plugin.xml - which I really prefer not to do. We extended the editor to listen to override createById so that we could keep a registry of some of our sub-elements in the process. That meant we had to change the editorClass for the paletteContribution, and override the editor with our own class name. This part wasn't too bad but still required a change to the GPD plugin.xml. Before I enter an enhancement request does anyone have any feedback or is there a better way to go about this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096065#4096065 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096065

18 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2007