April 2009 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Persisted mgmt edits not applied to AbstractBeanMetaData

by scott.stark＠jboss.org

That is probably due to a change I made to avoid duplicate ManagedObjects being created for the bootstrap beans. The ProfileServiceBootstrap.initBootstrapMDs only create a minimal ManagedObjectImpl for the KernelDeployments and then creates the MangedComponents for the DeplomentUnit components. Something is not lining up in terms of matching what is produced by the DeployersImpl approach to creating the root ManagedObject. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227940#4227940 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227940

15 years, 7 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jta transaction interceptor

by alex.guizar＠jboss.com

Must be because you are an admin. I'm just a keyboard worker :-P View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227930#4227930 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227930

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: ReplicateConnectionFailureTest failure on CI server

by clebert.suconic＠jboss.com

I think this may be related: I'm at the moment chasing a leakage on Connections. one of the places that I found was ConnectionManagerImpl.pingExecutor. If I called ConnectionManagerImpl.recreatePingExecutor() I could get a lot of references cleared. So, I also think connections are not being cleaned up somehow. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227928#4227928 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227928

15 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Persisted mgmt edits not applied to AbstractBeanMetaData

by bstansberry＠jboss.com

I'm experimenting with applying edits via the ManagementView to ServiceBindingManager (see http://www.jboss.org/index.html?module=bb&op=viewtopic&t=154673 for changes I've made locally to set this up.) I'm finding that my edits are persisted, but when I restart the AS they are not being applied. Problem seems to be the type of attachment is not being looked for. Here's how ProfileServicePersistenceDeployer looks for relevant attachments: | protected void internalDeploy(DeploymentUnit unit) throws DeploymentException | { | // Check all attachments, if they have a managed attachment | // TODO there might be a better way to do that ? :) | Set<String> attachments = unit.getTransientManagedObjects().getAttachments().keySet(); | for(String attachment : attachments) | { | PersistedManagedObject persistedManagedObject = (PersistedManagedObject) unit.getAttachment(PERSISTED_ATTACHMENT_PREFIX + attachment); | | if(persistedManagedObject != null) | ... do stuff to apply persisted edits | The "attachments" set includes: org.jboss.kernel.spi.deployment.KernelDeployment, org.jboss.deployers.spi.structure.StructureMetaData Problem is the LazyPredeterminedManagedObjects.attachments set only includes org.jboss.beans.metadata.plugins.AbstractBeanMetaData So, no match and thus no edits applied. Any ideas on what could be going wrong? The persisted attachment metadata is as follows: bindings-jboss-beans-XXX/metadata-attachment.xml: | <?xml version="1.0" encoding="UTF-8" standalone="yes"?> | <attachments-metadata xmlns="urn:org:jboss:profileservice:attachments:1.0"> | <attachment> | <attachment-class-name>org.jboss.beans.metadata.plugins.AbstractBeanMetaData</attachment-class-name> | <attachment-name>org.jboss.services.binding.ServiceBindingManager</attachment-name> | </attachment> | <deployment-name>bindings-jboss-beans.xml</deployment-name> | <deployment-structure> | <relative-order>0</relative-order> | </deployment-structure> | <last-modified>1241122388193</last-modified> | </attachments-metadata> bindings-jboss-beans-XXX/org.jboss.services.binding.ServiceBindingManager.attachment.xml: | <?xml version="1.0" encoding="UTF-8" standalone="yes"?> | <managed-object xmlns="urn:org:jboss:profileservice:persistence:managed-object:1.0" template-name="org.jboss.services.binding.ServiceBindingManager" name="ServiceBindingManager" class-name="org.jboss.beans.metadata.plugins.AbstractBeanMetaData"> | <orignal-name>ServiceBindingManager</orignal-name> | <properties> | <property name="serverName"> | <simple>ports-01</simple> | </property> | </properties> | </managed-object> (BTW, there's a typo in that last snippet: "orignal-name") View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227924#4227924 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227924

15 years, 7 months

1
0
0 / 0

[Design of POJO Server] - Moving ServiceBindingManager config out of bootstrap

by bstansberry＠jboss.com

For 5.1.0.GA, I'd like to move the SBM deployment out of the bootstrap. There's been discussion on the dev list of doing this for AS 6, since the ProfileService impl will support more fine-grained sub-profiles. But I see now it's needed for 5.1 as well if we ever want to be able to have editable managed objects for the SBM components.[1] I think getting that working in 5.1 is important, since it provides hooks for future mgmt tooling improvements. My work on JBAS-6259 shows me that with bindings.xml in the bootstrap, edits to the components aren't persisted. The reason SBM deployment is in the bootstrap is it has to come before conf/jboss-service.xml. But that doesn't mean it has to be in bootstrap. I propose to simply change StaticProfileFactory and expose a "bindingsURI" property, which if set will result in a sub-profile that deploys before the conf/jboss-service.xml sub-profile. I've done this locally and it works fine. Any comments? [1] https://jira.jboss.org/jira/browse/JBAS-6259 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227902#4227902 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227902

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - ReplicateConnectionFailureTest failure on CI server

by jmesnil

after I committed a fix for JBMESSAGING-1421 (r6641), ReplicateConnectionFailureTest.testFailConnection() is failing. I think the reason is the connection is no longer cleaned up when it is closed but only when the connection TTL is hit. However, the replicating connection is not checked by the remoting service impl FailedConnectionsTask and nobody will realize it must be cleaned up and we will never call fail() on it. I need to check that it is indeed what it happening. The fix would be to ensure that the replication connection is also checked by the RemotingService's FailedConnectionsTask but I'm not sure to see the whole implications wrt to replication. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227900#4227900 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227900

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another security configuration issue

by gaohoward

Ok, that clears my mind at last. Thanks. Then my question is gone. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227883#4227883 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227883

15 years, 7 months

1
0
0 / 0

[Design of POJO Server] - JBBOOT - Event listener and ServerInitializer APIs

by jaikiran

Moving the email discussion with ALR, to the forum: "jaikiran" wrote : > Hi Andrew, | > | > | > I was working on the JBBOOT-54 and had a few related questions: | > | > 1) In MCServer (impl-mc) what is the right time to expect the Kernel within the MC to be "set". Right now i see that it's being set during doStart() which is too late if someone wants to register to kernel events. I have this failing testcase (not committed) http://pastebin.com/m3979391c This fails because the kernel is not set. | "ALR" wrote : | Yep, I moved the bootstrap.run() and setup of the Kernel into the | initialize() method of AbstractMcServerBase. | | Commits: http://fisheye.jboss.org/changelog/JBossAS/?cs=87976 | "jaikiran" wrote : | > 2) I am bad (just learning more) at generics, this is more of a "is there a better way to do this" question - The LifecycleEventHandler has the following API: | > | > public void handleEvent(Server<MCServer, MCServerConfig> server, LifecycleState state) throws LifecycleEventException | > | > Assuming that the client registers a event handler for a MCServer event http://pastebin.com/m298f9c41is there a better was to work on a MCServer in the handleEvent method instead of doing a cast (line 26 in pastebin)? More importantly are there chances of getting a different type of server (i believe not, else it would be a bug), when the event handler was registered for MCServer? | "ALR" wrote : | The Lifecycle Event Handling API was stupid, because there's no need to | pass the server back into handleEvent(). So I removed this. Event | handlers that need to get at the server or Kernel (or whatever) can make | that an implementation detail supplied in the ctor, like: | | [url]http://fisheye.jboss.org/browse/JBossAS/projects/bootstrap/trunk/impl... | [/url] | Regarding your question about the generics, clearly they're wrong. And the same pattern is used in ServerInitializer. So I've got to revisit this and keep type safety (ideas welcome). | "jaikiran" wrote : > P.S: Is there an appropriate forum (user/dev) where we could discuss such questions? | "ALR" wrote : | Sure, we can abuse Design of POJO Server. Mind posting your questions and my responses there? | | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227860#4227860 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227860

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another security configuration issue

by timfox

"gaohoward" What's interesting is that 'jms.topic.news.europe.europeTopic' matches both 'jms.topic.#' and 'jms.topic.news.europe.#'. So I expect that it will return three roles: user, europe-user and news-user. But it actually returns 2 - europe-user and news-user. [/quote wrote : | | Returning just europe-user and news-user would be correct. | | Security settings are not inherited. I.e. the more specific matching set of permissions should take precedence. | | We need it that way otherwise we wouldn't be able to deny any roles on a more specific match, like I mentioned in my previous post. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227859#4227859 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227859

15 years, 7 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Another security configuration issue

by gaohoward

Hi Andy, here I rephrase my thought. Actuall it is about how the SecurityDeployer works with wild cards. Again let's take this config: | <security match="jms.topic.#"> | <permission type="createDurableQueue" roles="user"/> | <permission type="deleteDurableQueue" roles="user"/> | <permission type="createTempQueue" roles="user"/> | <permission type="deleteTempQueue" roles="user"/> | <permission type="send" roles="user"/> | <permission type="consume" roles="user"/> | </security> | | <security match="jms.topic.news.europe.#"> | <permission type="send" roles="europe-user"/> | <permission type="consume" roles="news-user"/> | </security> | | <security match="jms.topic.news.us.#"> | <permission type="send" roles="us-user"/> | <permission type="consume" roles="news-user"/> | </security> | Here we have three security elements. There match strings are | jms.topic.# | jms.topic.news.europe.# | jms.topic.news.us.# | Suppose we deploy the above config into SecurityDeployer. Given a topic whose address is 'jms.topic.news.europe.europeTopic', what if we call | HashSet roles = SecurityDeployer.securityRepository.getMatch('jms.topic.news.europe.europeTopic'); | What's interesting is that 'jms.topic.news.europe.europeTopic' matches both 'jms.topic.#' and 'jms.topic.news.europe.#'. So I expect that it will return three roles: user, europe-user and news-user. But it actually returns 2 - europe-user and news-user. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227858#4227858 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227858

15 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums April 2009