[Clustering/JBoss] - Re: Controlling cluster services
by bstansberryï¼ jboss.com
Sorry for slow response on this.
You've subclassed HAServiceMBeanSupport to implement MyClusterService. Do you need to do this in order for MyClusterService to do what it is supposed to? If not. don't subclass that class.
Do you need to subclass ServiceMBeanSupport (which is a superclass of HAServiceMBeanSupport) in order for MyClusterService to do what it is supposed to? If not, consider not subclassing that class either.
Next, decide what lifecycle steps you want MyClusterService to go through.
If you implement any of the methods named create() start() stop() destroy() then JBoss is going to invoke those methods when it deploys MyClusterService. This is not regulated by whether you are the master or not. (This is why you shouldn't subclass ServiceMBeanSupport if you don't need to and don't want to expose create/start/stop/destroy).
If you do implement create/start/stop/destroy, then your service really has a 6 step lifecycle:
create -- done at deployment time
start -- done at deployment time
startSingleton -- when becomes master
stopSingleton -- when stops being master
stop -- done at undeployment time
destroy -- done at undeployment time
I very much advise against trying to subclass HAServiceMBeanSupport and then overriding startService to check if you are the master. Mixing together the start and startSingleton lifecycle steps is just asking for trouble. If your service needs to do some startup work when it becomes the master and not before, implement it directly in startSingleton, not in startService.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100396#4100396
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100396
18Â years, 5Â months
[JBoss Seam] - Re: Writing SeamTests with Seam 2.0.0. CR2 - What's Changed?
by bsmithjj
It looks like when the local-jdbc connection pool manager is trying to connect to the DB, it's running into issues:
| 13:43:18,374 DEBUG org.jboss.ejb3.entity.PersistenceUnitDeployment.(start:187) - Found persistence.xml file in EJB3 jar
| 13:43:20,156 WARN org.jboss.resource.connectionmanager.JBossManagedConnectionPool.(getConnection:278) - Throwable while attempting to get a new con
| nection: null
| org.jboss.resource.JBossResourceException: No matching credentials in Subject!
| at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory.getConnectionProperties(BaseWrapperManagedConnectionFactory.java:472)
|
| at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:158)
| at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:586)
| at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:254)
| at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:580)
| at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:341)
| at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:351)
| at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:394)
| at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:838)
| at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
| at org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.getConnection(InjectedDataSourceConnectionProvider.java:47)
| at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:76)
| at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2006)
| at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1289)
| at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:691)
| at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:127)
| at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:246)
| 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.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:55)
| at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:108)
| at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:103)
| at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:145)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.installAction(KernelControllerContextAction.java:197)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.install(KernelControllerContextAction.java:136)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:233)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:724)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:445)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:555)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192)
| at org.jboss.kernel.plugins.dependency.AbstractKernelController.install(AbstractKernelController.java:84)
| at org.jboss.kernel.plugins.dependency.AbstractKernelController.install(AbstractKernelController.java:78)
| at org.jboss.ejb3.MCKernelAbstraction.install(MCKernelAbstraction.java:141)
| at org.jboss.ejb3.Ejb3Deployment.startPersistenceUnits(Ejb3Deployment.java:519)
| at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:324)
| at org.jboss.ejb3.deployers.EJBStage2Deployer.deploy(EJBStage2Deployer.java:54)
| at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52)
| at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:170)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:592)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:476)
| at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:406)
| at org.jboss.embedded.DeploymentGroup.process(DeploymentGroup.java:128)
| at org.jboss.embedded.Bootstrap.deployResourceBases(Bootstrap.java:307)
| at org.jboss.seam.mock.EmbeddedBootstrap.startAndDeployResources(EmbeddedBootstrap.java:14)
| at org.jboss.seam.mock.BaseSeamTest.startJbossEmbeddedIfNecessary(BaseSeamTest.java:1006)
| at org.jboss.seam.mock.BaseSeamTest.init(BaseSeamTest.java:931)
| at org.jboss.seam.mock.SeamTest.init(SeamTest.java:42)
| 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.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:645)
| at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:385)
| at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:141)
| at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:79)
| at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:158)
| at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:103)
| at org.testng.TestRunner.runWorkers(TestRunner.java:673)
| at org.testng.TestRunner.privateRun(TestRunner.java:620)
| at org.testng.TestRunner.run(TestRunner.java:480)
| at org.testng.SuiteRunner.runTest(SuiteRunner.java:278)
| at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:273)
| at org.testng.SuiteRunner.privateRun(SuiteRunner.java:253)
| at org.testng.SuiteRunner.run(SuiteRunner.java:168)
| at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:987)
| at org.testng.TestNG.runSuitesLocally(TestNG.java:951)
| at org.apache.maven.surefire.testng.TestNGExecutor.executeTestNG(TestNGExecutor.java:161)
| at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:101)
| at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
| 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.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:275)
| at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:832)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100393#4100393
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100393
18Â years, 5Â months
[JBoss Seam] - Re: E-mail attachment: HTML IMG for attached image
by sandy_brydon
I am having trouble with how an inline attachment is supposed to work since it doesn't seem to be creating a boundary with Content-Type: multipart/related around the attachment, it merely relies on the outer multipart/mixed boundary defined in the header of the email.
The effect is that my email client (Thunderbird) is treating the image as an attachment and is not placing it inline.
...
| <m:attachment
| value="#{emailService.params.get('img_logo')}"
| fileName="logo.gif"
| status="logo"
| disposition="inline" />
| <img src="cid:#{logo.contentId}" alt="logo" />
| ...
(the attachment value references a java.net.URL - i doubt this matters, but just in case)
everything else appears to be correct:
- the header for the logo:
Content-Type: image/gif; charset=ISO-8859-1; name=logo.gif
| Content-Transfer-Encoding: base64
| Content-ID: <ckgkyystehilrvoyfavc>
| Content-Disposition: inline; filename=logo.gif
- the corresponding img tag:
<img src="cid:ckgkyystehilrvoyfavc" alt="logo" />
is this incorrect? perhaps i have misconfigured something?
jboss-4.2.1.GA
jboss-seam-2.0.0.CR3
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100391#4100391
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100391
18Â years, 5Â months
[Security & JAAS/JBoss] - Re: Problem securing NamingService, InvokerAdaptorService on
by kasimier
thanx for the info about the log level. I got a fine grained trace about what´s going on now, but the issue isn´t clear to me:
the security relevant services (configured in a own sar) are created correctly and my PolicyConfig named "lcfg" is loaded correctly too. Don´t know if this matters, but JaasSecurityManagerService says nothing about a configured securityMgrCtxPath named "java:/jaas/lcfg"
I have configured my NamingService XMBean with the following interceptors:
| <descriptors>
| <interceptors>
| <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/lcfg" />
| <interceptor code="org.jboss.mx.interceptor.PersistenceInterceptor2" />
| <interceptor code="org.jboss.mx.interceptor.ModelMBeanInterceptor" />
| <interceptor code="org.jboss.mx.interceptor.ObjectReferenceInterceptor" />
| </interceptors>
| </descriptors>
and of course the JRMPProxyFactory for the Naming service.
Further I got a JRMPProxyFactory for the InvokerAdaptorService. InvokerAdaptorService is configured with following interceptors on it´s invoke() method:
| <operation>
| <name>invoke</name>
| <parameter>
| <name>invocation</name>
| <type>org.jboss.invocation.Invocation</type>
| </parameter>
| <return-type>java.lang.Object</return-type>
| <descriptors>
| <interceptors>
| <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/lcfg"/>
| <interceptor code="org.jboss.jmx.connector.invoker.SerializableInterceptor" policyClass="StripModelMBeanInfoPolicy"/>
| </interceptors>
| </descriptors>
| </operation>
| </xmbean>
When I connect to the MBeanServer via standard org.jnp.interfaces.NamingContextFactory, I can read all registered objects, without auth or error, of course jmx/rmi/RMIAdaptor too.
I also can call invoke() on jmx/rmi/RMIAdaptor without auth or error.
The security log trace when I stop a web module via invoke() does not say much, or I cannot interpret it correctly:
....
2007-10-29 18:13:09,796 TRACE [org.jboss.security.SecurityAssociation] pushSubjectContext, subject=null, sc=org.jboss.security.SecurityAssociation$SubjectContext@912f10{principal=null,subject=null}
....
2007-10-29 18:13:11,093 TRACE [org.jboss.security.SecurityAssociation] popSubjectContext, sc=org.jboss.security.SecurityAssociation$SubjectContext@1e2e8cc{principal=null,subject=null}
2007-10-29 18:13:11,109 TRACE [org.jboss.security.SecurityAssociation] pushSubjectContext, subject=null, sc=org.jboss.security.SecurityAssociation$SubjectContext@aa780b{principal=null,subject=null}
2007-10-29 18:13:11,109 TRACE [org.jboss.security.SecurityAssociation] popSubjectContext, sc=org.jboss.security.SecurityAssociation$SubjectContext@aa780b{principal=null,subject=null}
2007-10-29 18:13:13,281 TRACE [org.jboss.security.SecurityAssociation] pushSubjectContext, subject=null, sc=org.jboss.security.SecurityAssociation$SubjectContext@1eb186a{principal=null,subject=null}
2007-10-29 18:13:13,281 DEBUG [org.jboss.system.ServiceController] stopping service: jboss.web.deployment:war=iwa.war,id=-1069725553
....
....
2007-10-29 18:13:13,531 DEBUG [org.apache.catalina.core.ContainerBase] unregistering jboss.web:j2eeType=WebModule,name=//localhost/iwa,J2EEApplication=none,J2EEServer=none
2007-10-29 18:13:13,531 TRACE [org.jboss.web.tomcat.security.config.JBossContextConfig] destroy called with DELEGATE_TO_PARENT=false
2007-10-29 18:13:13,531 TRACE [org.jboss.security.jacc.JBossPolicyConfiguration] delete
2007-10-29 18:13:13,531 DEBUG [org.jboss.web.WebModule] Stopped jboss.web.deployment:war=iwa.war,id=-1069725553
....
....
Really have no idea what kind of problem pains me.
Maybe I have to force creation of the policy config before Interceptors using a JAAS domain are created?
Maybe I must not configure InvokerAdaptorService, JRMPInvoker aso, directly in myServer/conf/jboss-service.xml?
btw: securing a web application with the same JAAS domain works fine and forces my browser to pop up the login dialog.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100390#4100390
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100390
18Â years, 5Â months
[JBoss Portal] - Re: Redirects in doView
by chris.laprunï¼ jboss.com
"amin-mc" wrote : But (this is probably not possible) is it possible to change/replace a portlet window from interacting with another portlet. For example
|
| Portlet A
| Portlet B
| Portlet C
| Portlet D
| Portlet E
|
| Currently I can see A, B and C, D. If i interact with D is it possible to change C to E? Or is the only option is to change the content of C?
|
| Not sure if that made sense!
It might be possible using Portal's API (though I haven't tried to do so) but your portlets would not be JSR-168 compliant anymore. There is nothing in the JSR 168 specification to do what you want. Actually, inter-portlet communication (IPC) is outside of the specification so any coordination of work between portlets you are trying to do would have to use a vendor-specific mechanism. This is true for JBoss Portal, but it would also be the case with any other portal vendor.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4100389#4100389
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4100389
18Â years, 5Â months