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

[Design of JCA on JBoss] - Re: TODO: Interceptors

by vickyk

Yes I was able to have a look at the couple of projects here http://fisheye.jboss.org/browse/JBoss/jboss-jca http://fisheye.jboss.org/browse/JBoss/rars When are you planning to get them incorporated in the svn trunk , are these changed not to be released with Jboss5 finally . View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062532#4062532 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062532

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - AccessControlTestCase

by Kevin.Conner＠jboss.com

The above test case is currently failing within the kernel module when executed under maven. The reason for the failure is the name of the directory containing the test classes. :) There is a security policy in effect for the tests, TestsPolicyPlugin, which is responsible for assigning the permissions based on the code source. This policy class allows the permissions to be configured via a property file (not used in this case) if it believes that the code source represents a test location. How does it determine whether the code source represents tests? Simple, it looks for 'tests' or '-test.jar' in the name of the code source (last directory/file only). If the code source represents a test location then it is given a specific set of permissions plus the ones specified in the property file. If it does not represent a test location then it defaults to all permissions. If this is run in the current eclipse setup then it works, the final directory is tests-classes (almost certainly a typo of mine). If this is run via maven then it fails as the final directory is test-classes. :( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062528#4062528 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062528

18 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Uniquely identifying services and actions

by tfennelly

"tcunning" wrote : Do we need both the action name and the action instance name? Shouldn't we be able to get by with just one of these, since the instance name should be unique within the particular service? Yeah, I was wondering about that too. Surely the action name is all that's needed and that only needs to be unique on a per service basis, right? "tcunning" wrote : With the nickname approach is it possible to enforce uniqueness across nodes, or would the "nickname" only be unique within a particular node? Personally I think the nickname will drive people bats because they'll need to perform some form of translation/mapping. I'd think that the name people see should be all they need to have to take them directly to the service/action definition in question i.e. no translation required. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062527#4062527 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062527

18 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Uniquely identifying services and actions

by tcunning

"mark.little(a)jboss.com" wrote : "burrsutter" wrote : Actions vs Services for naming... | | | | From the user's perspective Actions are not unique since they can be reused from service to service by wiring in via the jboss-esb.xml. | | | | Yes, but within a deployment, the combination of esb instance, service name, action name and action instance name will be unique. | I'm not wholly against the concatenation approach, but it : a) should be short as possible b) should be something the users will recognize (and I think the most recognizable piece of information is the esb instance name) Do we need both the action name and the action instance name? Shouldn't we be able to get by with just one of these, since the instance name should be unique within the particular service? With the nickname approach is it possible to enforce uniqueness across nodes, or would the "nickname" only be unique within a particular node? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062520#4062520 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062520

18 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4276 Discussion Thread

by bstansberry＠jboss.com

Related discussion: in HA-JNDI this attribute is named "ClusterPartition". Elsewhere it's named "Partition". Since we're changing things, now's the time to clean things up and make them consistent. Three choices: 1) Change HA-JNDI and call it "Partition". 2) Change others to "ClusterPartition". I reject this because ClusterPartition is the name of a particular impl of HAPartition. 3) Change everything to "HAPartition". Any thoughts on this Jerry? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062513#4062513 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062513

18 years, 9 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - JBAS-4276 Discussion Thread

by bstansberry＠jboss.com

Discussion of http://jira.jboss.com/jira/browse/JBAS-4276. Previous discussion taken from JIRA comments: "Jerry Gauthier" wrote : Brian - I think you're already done this work. I couldn't find any configuration files in cluster\src\etc where we're injecting a partition name instead of HAPartition. Yes, but IIRC there are a lot of places where ClusterPartitionMBean is the type of a property. That's JMX-centric and AS 5 should be POJO-centric. So, we need to look at the interfaces and move toward making HAPartition the property type. Also, no setter for a String partition name. anonymous wrote : Brian - for clarification before I proceed with this work. | | Using the HA-JNDI service as an example, you've already modified the configuration file (cluster-beans.xml) to inject HAPartition instead of the ClusterPartition mbean. However the property type of attribute "clusterPartition" in DetachedHANamingService is ClusterPartitionMBean. I need to change the type to org.jboss.ha.framework.interfaces.HAPartition. Is this correct? Yes, this is correct. Also don't want to expose setPartitionName(). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062509#4062509 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062509

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: MetaBridge

by thomas.heute＠jboss.com

It works now ;) it should solves Chris issue as well since it's using myFaces and its bridge View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062495#4062495 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062495

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: MetaBridge

by julien＠jboss.com

we should try to pursue in using MyFaces with JBossAS 4.2 and 4.0.5 I hope to look at it soon. "thomas.heute(a)jboss.com" wrote : To solve the problem of having our two JSF portlets (core-admin and core-wsrp) work on both JBoss AS 4.0.5 (with embedded myFaces) and JBoss AS 4.2.0 (with embedded Sun RI JSF implementation), we came up with a "MetaBridge" http://wiki.jboss.org/wiki/Wiki.jsp?page=PortalJSFMetaBridge | | While it worked well for our portlets, it brought a load of other issues for other portlets deployment as the core-admin (and core-wsrp) is not isolated (other portlets trying to start the meta-bridge, people willing to use myFaces instead of Sun RI...) | | One option would be to include the myFaces implementation inside the core-admin.sar package and isolate the sar in its own classloader, i didn't succeed unfortunately, not sure why. | | So the safest way would be to only support JBoss 4.2.0 and Sun RI (despite the current low quality of the portlet bridge). | | Thoughts ? Any idea ? | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062491#4062491 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062491

18 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MAVEN: activation-1.0.2.jar not being fetched

by Kevin.Conner＠jboss.com

"kabir.khan(a)jboss.com" wrote : I've resolved this locally by copying M2_REPO/javax/activation/activation/1.1/activation-1.1.jar to M2_REPO/javax/activation/activation/1.0.2/activation-1.0.2.jar, but the deeper cause needs to be adressed I still think these should be generated by maven ;). Try this instead mvn eclipse:clean | mvn -Peclipse This will create your .project/.classpath/.settings files to reflect the current dependencies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062487#4062487 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062487

18 years, 9 months

1
0
0 / 0

[Design of JBoss Portal] - Re: MetaBridge

by chris.laprun＠jboss.com

I have determined that the combination of MetaBridge and JSF RI causes the WSRP GUI to not work properly. This issue has been traced back to the fix Julien did to set the facelets.BUILD_BEFORE_RESTORE parameter. I am not quite sure what happens exactly but that has an impact on how immediate components are handled. It would be good to be able to work out of the box on both 4.0.5 and 4.2 but we would need to be able to test our JSF components on both MyFaces and RI automatically. As of now, the MetaBridge introduces some unknown into the process and without tests it's difficult to make sure our apps behave properly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4062485#4062485 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4062485

18 years, 9 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 July 2007