March 2008 - jboss-dev-forums - Jboss List Archives

[Design of Management Features on JBoss] - Re: Use of JBAS5 management api's by user apps

by scott.stark＠jboss.org

"charles.crouch(a)jboss.com" wrote : So only spec defined metadata is managable for things like .wars and .ears because those are the only things the which the .war and .ear deployers knows about? | Yes. An aspect overrides the deployment metadata to incorporate the management changes. "charles.crouch(a)jboss.com" wrote : | So if you wanted to add support for non-spec defined metadata you would need to write another deployer? That is not going to help as deployers run off of the deployment metadata attachments. If it was an mc bean property, or jmx mbean property that controlled the frequency, it would already be managable via the corresponding component deployer. So, if you make your configuration object an mc mbean, and then inject it, you would have a managable configuration object. We should allow injection of mc beans into ee components via an @Resource(...) annotation. Otherwise, you would have to replicate behavior the profile service/deployers perform for deployment metadata. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133692#4133692 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133692

16 years, 1 month

1
0
0 / 0

[Design of Management Features on JBoss] - Re: Use of JBAS5 management api's by user apps

by charles.crouch＠jboss.com

So only spec defined metadata is managable for things like .wars and .ears because those are the only things the which the .war and .ear deployers knows about? So if you wanted to add support for non-spec defined metadata you would need to write another deployer? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133689#4133689 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133689

16 years, 1 month

1
0
0 / 0

[Design of Management Features on JBoss] - Re: Use of JBAS5 management api's by user apps

by scott.stark＠jboss.org

The integration point for the management interface is the deployer associated with the component with the annotations. As long as the deployer implements the ManagedObjectCreator interface, the component will be manageable. As long as the component property maps to a piece of metadata for the component deployment, its managable. If your talking about non-spec defined metadata (not an env-entry, config parameters, etc.), then annotating would not have any effect. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133685#4133685 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133685

16 years, 1 month

1
0
0 / 0

[Design of JBossCache] - JBCACHE-1303 -- Invalidation not transactional

by bstansberry＠jboss.com

Discussion thread for http://jira.jboss.com/jira/browse/JBCACHE-1303. I think the essence of the issue here is the cache has no mechanism for doing a rollback of an invalidation. So, if you send out a set of invalidations as part of a PREPARE call, there is no way to undo them with a subsequent ROLLBACK. With PL, this is less of an issue, since even if you don't roll back the invalidation on the other nodes, the cluster remains in a "consistent" state per the invalidation-semantics. That is, for a given FQN, every node in the cluster either has that node with the same state, or doesn't have the node. This is why I say in point #2 in the JIRA description that it's less of an issue. At least that's what I think; comments welcome. :) For OL, the problem is harder since the invalidation changes the DataVersion of the "tombstone" node. Here, some sort of rollback is needed. Perhaps though it is sufficient to restore the data version to the "tombstone" in the rollback operation. A side benefit of fixing this is invalidation currently doesn't batch the invalidation messages for a tx. So, if you change 10 nodes in a tx, as part of tx commit JBC sends out 10 invalidation messages. Using a normal PREPARE would eliminate that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133684#4133684 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133684

16 years, 1 month

1
0
0 / 0

[Design of Management Features on JBoss] - Use of JBAS5 management api's by user apps

by charles.crouch＠jboss.com

Is it going to be theoretically/practically possible for user applications to make use of the same annotations currently being added to the Datasource/JMS components in AS5? The idea here would be for a regular .war/.ear application to benefit from the profileservice/metadata repository functionality which is built into the app server. For example, I have an app that runs a batch job every 60minutes, I would like to make this frequency configurable, but don't want to deal with making this configuration persistent and reading/updating it etc. Instead I just want to annotate that this property and its parent class with the appropriate ManagedProperty/ManagedObject/ManagedComponent annotations, so that I can query the profile service for a management interface, then set the new frequency value, and know that that new value is going to be set on my component when the app server restarts? I guess this would be somewhat analogous to having user apps make use of the JMX server in JBAS4.x... Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133682#4133682 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133682

16 years, 1 month

1
0
0 / 0

[Design of EJB 3.0] - Re: Restricting scanning for ejbs

by scott.stark＠jboss.org

No, we don't scan the root of the war anymore. This particular deployment has ejbs in the WEB-INF/classes. Its packaged in an ear with an ejb jar with this classes as well, and that is the deployment that sources these based on the ear definition. As a javaee5 artifact this is arguably an invalid packaging. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133678#4133678 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133678

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: cts config startup issue with current vfs trunk

by alesj

"scott.stark(a)jboss.org" wrote : So why is the trace showing the super method? No idea. Can you push in the tests and I'll see what's the deal on my machine. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133677#4133677 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133677

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: cts config startup issue with current vfs trunk

by scott.stark＠jboss.org

Hmm, must be an old c++ carry over I had. So why is the trace showing the super method? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133670#4133670 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133670

16 years, 1 month

1
0
0 / 0

[Design of JBoss Build System] - Re: JBossAS CR1 build plan

by scott.stark＠jboss.org

All the deployers have been moved out. I'll move the launcher out today. Aspects can just be moved to its own project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133659#4133659 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133659

16 years, 1 month

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MC + JAXB (JBossXB Builder)

by alesj

"adrian(a)jboss.org" wrote : | 3) ... update the Spring parsing. | Do we really want to also re-write Spring schema into JBossXB Builder annotated metadata, hence removing the .xsd file? I don't really want to modify/remove anything that exists in Spring. But on the other hand, we're already doing that by shipping slightly modified schema file (due to that fix with infinity * infinity). Doing that also defeats the purpose of having single metadata to handle both schemas, MC and Spring's. Since the functionality is almost the same, it's the attribute and element names that differ. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133649#4133649 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133649

16 years, 1 month

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 March 2008