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

[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository

by weston.price＠jboss.com

Issue: The old method of deployment used the RAR->MCF (via the OldRARDeployment attribute) dependency to force the MCF to wait for the RAR to be deployed prior to the MCF entering the start/stop lifecycle. Without this explicit dependency I am running into the case where the *-ds.xml file gets parsed and all the MBeans get created prior to the RAR being deployed. Assuming that one of the reasons for repository is to remove the requirement to specify the RAR name in the *-ds.xml, jboss.xml or jboss-service.xml file, this would seem to be problematic due to the inherent dependency between them. I am not sure the real value of this anyway as you would expect a deployment type of MCF, listener, AdminObject to specify to which RAR it belonged. Obviously this is not the only reason for the repository, but I can't quite see how we can get away with getting rid of the RAR names from our deployments. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011035#4011035 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4011035

19 years, 2 months

1
0
0 / 0

[Design of JBoss Profiler] - Re: Profiler works for some ops, but not all, on Suse & jbos

by pdpantages

I rebuilt the native library linux/libjbossAgent.so Seems OK now..... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4010998#4010998 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4010998

19 years, 2 months

1
0
0 / 0

[Design of JBoss Portal] - Re: jportal

by jimisola

Hi Gurdipe, I seem to be in the same situation now that you were two months ago. I'm very curious on what your experience is with JBoss Portal. Did you decide to go with it? Any problems? My list of features is not as long as yours, but it would be interesting to here you experience with 1. news: ability to post news to the site (e.g. last five are shown on the right hand side) 2. picture gallery (with basic functionality such as category/labels, ACL etc) 3. address book / contact list (for former student) 4. forum / message board (nice to have: ACL) 5. file sharing/storing using web, WebDAV etc (for meeting protocols etc, ACL) Kind regards, Jimisola View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4010967#4010967 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4010967

19 years, 2 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Backport to 1_0_1_SP1 has broken the test suite

by timfox

ROFL View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4010926#4010926 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4010926

19 years, 2 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: Programmatic deployment--Redux

by weston.price＠jboss.com

Ok, this is working in rough draft form. This still requires quite a bit of testing but at this point a new | org.jboss.resource.deployers.ManagedConnectionFactoryDeployer | has been created to read/parse the *-ds.xml file and create the MBeans. One thing I did have to do was leverage the ServiceMetaDataParser to manage MBean definitions within the *-ds.xml file. Rather that simply redo all this work I just leveraged the existing API. The parser is JAXP based and is optimized for JDBC based deployments. The underlying MetaData model is straightforward. Note, all meta data generated is now kept in the RARMetaDataRepository and associated with the ConnectorMetaData pointing to the actual RAR. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4010866#4010866 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4010866

19 years, 2 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository

by weston.price＠jboss.com

Also, with the new Repository we should rethink deployment of MessageEndpoints as ActivationSpecs are also in the repository. This should make this cleaner and less hackish and will allow us to get away from having to provide a RAR name in most cases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4010864#4010864 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4010864

19 years, 2 months

1
0
0 / 0

[Design of JCA on JBoss] - Re: JBAS-1437 RARMetaDataRepository

by weston.price＠jboss.com

This is working in 'rough draft' at this point and coupled with the new programmatic deployment (JBAS-1425) goes a long way toward eliminating the XSL deployer all together. One 'hack' that I did put in was to set the JNDI name in the ManagedConnectionFactory on deployment. This makes resolving an entry in the repository much easier if multiple connection definitions exist in the repository (eg our JDBC adapters). I can't see anything necessarily wrong with doing this as it's simply a mechanism to avoid failing on a deployment when the RAR can't be guessed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4010863#4010863 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4010863

19 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: CacheListener events for state transfer marshalling

by manik.surtani＠jboss.com

:-) Ok, if that's the case then I will veto it for 2.0.0. I was just concerned that you did not have any other way to be compliant with the EJB3 spec. Since you do, I'd rather not have this callback. I think this is a very specific callback (region being marshalled for ST) and is very implementation/release specific, and only will be of use to very few applications/use cases. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4010843#4010843 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4010843

19 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: CacheListener events for state transfer marshalling

by bstansberry＠jboss.com

I was too wishy-washy above. I meant: "No, I don't want this for 1.4.1.SP1". View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4010842#4010842 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4010842

19 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: CacheListener events for state transfer marshalling

by bstansberry＠jboss.com

No, I don't think I want this for 1.4.1.SP1. I think I can use something like this: 1) Call prePassivate before caching any context. 2) Call postActivate after getting any context (to hand out to a request). That means the context will be in the passivated state when state transfer occurs. Whether in 2.0 having an event anyway makes sense, I still think it does, as it's a pretty major operation to happen to a node (bigger IMHO than a visit) and we emit callbacks for everything. But I don't feel at all strongly about it. How about this -- if you (or anyone) think it's really bad, veto it and we're done. :-) If you don't think it's that bad an idea, I'll open an unassigned JIRA for Beta2. If someone (aka Brian) gets it done, fine. If not, we WON'T_FIX the JIRA. Feature prioritization. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4010835#4010835 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4010835

19 years, 2 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 February 2007