September 2008 - jboss-dev-forums

[Design of POJO Server] - Towards a cononical server

by scott.stark＠jboss.org

One thing on the agenda for next week is moving towards a canonical server configuration model where the profile service repository has one jar/deployment regardless of how many configurations its used in. Related tasks: Define initial persistent format of the profile repository https://jira.jboss.org/jira/browse/JBAS-3768 OSGi Bundle Repository support https://jira.jboss.org/jira/browse/JBAS-4363 http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4040005 Refactor the conf/jboss-service.xml services ; should be remove conf/jboss-service.xml https://jira.jboss.org/jira/browse/JBAS-4814 Split system and application deployments https://jira.jboss.org/jira/browse/JBAS-5954 Re-package system deployments https://jira.jboss.org/jira/browse/JBAS-5955 The first hurdle is updating the build to produce a repository of jars/deployments, and then properly describing: - the class dependency requirements for deployments - the association of deployments with profile service configurations; (minimal, default, all, ...) This is what I'm starting to look at. How this is split up for what gets done for the 5.0.0.GA, EAP and future 5.1 releases is an issue as well since we are pressed to get the 5.0.0.GA/EAP out. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176870#4176870 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176870

17 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Re: JNDI Bindings

by jaikiran

"ALRubinger" wrote : | So I read many @RemoteBindings as targeted to expose any N number of bindings for the Default Business Interface Proxy. | | So if we have: | | @RemoteBinding(jndiBinding="Busi1") | | public interface MyBusinessInterface1{...} | | | | @RemoteBinding(jndiBinding="Busi2") | | public interface MyBusinessInterface2{...} | | | | public interface MyBusinessInterface3{...} | | | | @Stateless | | @RemoteBindings({ | | @RemoteBinding(jndiBinding="MyBean") | | @RemoteBinding(jndiBinding="MySSLBean", clientBindUrl="sslsocket://0.0.0.0:3843") | | }) | | public class MyBean implements MyBusinessInterface1, MyBusinessInterface2, MyBusinessInterface3{...} | | ..then we've defined @RemoteBindings at both the interface and EJB level. As a user I'd expect to find in the JNDI Tree: | | + Busi1 (Proxy implements MyBusinessInterface1) | | + Busi2 (Proxy implements MyBusinessInterface2) | | + MyBean (Proxy implements MyBusinessInterface1, MyBusinessInterface2, MyBusinessInterface3) | | + MySSLBean ((Proxy implements MyBusinessInterface1, MyBusinessInterface2, MyBusinessInterface3) < Exposes SSL Transport | | This way, an interface-targeted JNDI Binding is specified at the interface level, and any @RemoteBinding(s) on the class level apply to all Remote Business Interfaces. And it'd require no API changes. | | Going by what we are suggesting here, it looks like we are trying to provide an option for the bean developer to specify multiple bindings for the default business interface proxy. 1) One of the possible reasons, that i can think of, why the bean developer would want to do this is to provide a different transport to use. Is there any other valid reason why the developer would want to do this? 2) Does this multiple bindings apply on to Remote business interfaces? Is there any specific reason why the same reasoning can't be used to have something like @LocalBindings? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176864#4176864 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176864

17 years, 6 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Modularising the appserver bootstrap

by kabir.khan＠jboss.com

"adrian(a)jboss.org" wrote : I think there's also a dependency with the AspectManager bean expecting | ServiceMBeanSupport to be available. | | But JMX deployment should come after AOP. | | The eventual idea is to make JMX optional. I am putting the original AspectManagerService code in a delegate and wrapping that in a POJO (MC/AS5) and in a class extending ServiceMBeanSupport (AS4). However, the original code contains a few methods to do with JMX from ServiceMBeanSupport such as sending out JMX notifications, getting the ObjectName of the service, getting the MBeanServer etc. Can all that stuff be left out for the MC/AS5 version? I am not really clear on how the MC beans eventually get mapped onto JMX in AS5. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176848#4176848 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176848

17 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: Removing SFSB in HttpSessionListener

by bstansberry＠jboss.com

Good question; yes the default will be controllable via system property "jboss.web.clustered.session.notification.policy". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176846#4176846 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176846

17 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: Removing SFSB in HttpSessionListener

by jiwils

"bstansberry(a)jboss.com" wrote : Class name of the policy impl to use would be specified in jboss-web.xml. For now we'd ship two standard impls, one of which provides the existing behavior, one of which suppresses HttpSessionListener and HttpSessionAttributeListener notifications when a session is expired due to undeploy. Would it still be possible to have a system property change the default class, or were you thinking jboss-web.xml only? It seems like you might want to change the default globally rather than have to rebuild an application that ran into this problem. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176839#4176839 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176839

17 years, 6 months

1
0
0 / 0

[Design of Clustering on JBoss] - Re: Removing SFSB in HttpSessionListener

by bstansberry＠jboss.com

"pete.muir(a)jboss.org" wrote : (which leads to the SFSB's remove method being called unless you explicitly ask it not to). How do you "explicitly ask it not to"? The timing of this work is being driven by a support case where the customer is having issues because of the sessionDestroyed call. If there's a workaround, that would be great. anonymous wrote : I can't immediately see any other cases. Would including HttpSessionActivationListener in the policy be helpful? Allow/disallow the passivation/activation callbacks that surround replication. Norman Richards told me earlier this year that those were causing issues for you guys, although you found a workaround. anonymous wrote : Also, it's worth noting that in JBoss 5 we have the ability to automatically insert classes into a Seam apps classpath, allowing us to plugin alternative behaviour - this might be helpful here (Seam currently doesn't provide for plugability here, but it could if needed). The way I'd been thinking about configuring this is user specifies the classname of the policy they want to use in jboss-web.xml. That would end up in the JBossWebMetaData for the war (WebMetaData in 4.x). If Seam had the ability to manipulate the metadata to specify an appropriate policy impl, that would be nice for users. For AS 5 I was thinking of having the default policy impl be the Seam-appropriate one that disallows the sessionDestroyed callbacks on undeploy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176828#4176828 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176828

17 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Re: Problem with ldap Configuration in jboss portal

by thomas.heute＠jboss.com

Please use the User Forum for questions. Moving the topic. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176825#4176825 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176825

17 years, 6 months

1
0
0 / 0

[Design of JBoss Portal] - Problem with ldap Configuration in jboss portal

by javauser007

Hi, I'm using jboss portal 2.6.5 and open ldap. I have created an .ldif file according to my company requirements and it works fine with other applications except Jboss portal. My problem is, in my .ldif file i mentioned "my-user" for holding username and "my-pwd" for holding password. and in my ldap_identity-config.xml file i mentioned accordingly as givebellow. uidAttributeID my-user passwordAttributeID my-pwd But while i'm trying to access i'm not getting any error on console and simply the page is redirected to some other error page which shows "The user doesn't exist or the password is incorrect " .and in log file i'm getting the message like "Bad password for the user XXXXX" (even if i entered correct user name and password), but if i use "userPassword" name for holding the password in .ldif file it works fine. if i use "userPassword" name and even if i disabling the following code in ldap_identity-config.xml it works fine. passwordAttributeID userPassword But i should mention uidAttributeID like below uidAttributeID my-user and after doing some R&D on this, finally i came to know that the jboss is not at all reading the following snipet. passwordAttributeID my-pwd but my requirement is i should use "my-pwd" attribute id for holding the password. How to do that..? any help is appriciated....... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176823#4176823 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176823

17 years, 6 months

1
0
0 / 0

[Design of JBoss Profiler] - Feedback on trying jboss-profiler-2.0.Beta2.tar.gz

by biehl

1) The wikipage http://wiki.jboss.org/wiki/JBossProfiler - is outdated. Should it be updated with info about the new 2.0 profiler? (I can help) 2) On http://www.jboss.org/jbossprofiler/ there are two links under Download marked "2.0 Beta 2". They both point at http://www.jboss.org/downloading/?projectId=jbossprofiler&url=/jbossprofi... This is a bit confusing. When reading the readme: 3) I think why is there not an ant-task to "deploy" ie. copy jar-files and property file to the right directories. 4) Why is there no description where to put the dependencies (eg. javassist.jar) 5) Of the listed dependencies only javassist.jar needed to be added to JBOSS_HOME/lib to start the server. 6) anders@anders-desktop:~/opt/jboss/jboss-profiler-2.0.beta2$ java -jar jboss-profiler-client.jar startProfiler gives no output, and anders@anders-desktop:/opt/jboss/jboss-4.2.3.GA/bin$ ./twiddle.sh invoke 'org.jboss.profiler:service=Profiler' startProfiler 'null' outputs 'null' ++++++++++++++ How can I help improve the documentation and usability of JBoss profiler? Best Anders View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176817#4176817 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176817

17 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Re: Common marshalling infrastructure

by david.lloyd＠jboss.com

OK so I thought I'd post an update. The basic framework is "Almost Done (tm)", and so I just want to quickly mention some things that ended up different in the implementation from what was mentioned previously here. The ability to create object instances is now pluggable via the Creator interface. I provide two implementations: one that just uses reflection, and one that uses the Sun-specific method to create a constructor if a suitable one does not exist. Object and Class marshallers are no longer separated. This looked good on paper but turned out to be totally useless in practice. Instead, there is a notion of ClassResolvers (this is where you plug in your customized classloader configuration), ClassTables (predefined classes by ID), and ObjectTables (predefined objects by ID). Externalizers now can create object instances, so it's possible to serialize and deserialize an entire payload without using reflection at all. Finally, I've created some abstract base classes to make it easier to create a marshaller implementation. Right now we're working on a full-featured "native" implementation, as well as a Java-compatible implementation. Clebert had mentioned that he should be able to produce a JBSER-compatible implementation as well. Here's the updated API: http://tinyurl.com/6yme33 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4176813#4176813 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4176813

17 years, 6 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 September 2008