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

[Design of EJB 3.0] - Re: EJBTHREE-1454 Encapsulate Container infomation in TO/VO

by bstansberry＠jboss.com

Having the container name available to proxy-clustered in unbindEjb would be a minor convenience (let's me do some cleanup that would only be necessary if there's a bug). So, count that as a tiny vote for passing the InvokableContext. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171926#4171926 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171926

17 years, 7 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Improvements

by epbernard

I partly agree with you Andrew. I think the right level for a CI / Snapshot use is to define the targeted branch (say 3.3 for Hibernate Core) at the Jboss AS level. From here, the snapshot build of JBoss AS should get the latest published snapshot for that release (ideally it should get it from SVN, I don't see why we should have to manually push a snapshot out). Now, when it's time to release AS (beta, cr, ga, alpha etc), specific versions (ie non snapshots) should be chosen manually (as it is today), no question about that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171919#4171919 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171919

17 years, 7 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Improvements

by ALRubinger

Ah crap, I hadn't considered snapshots brought in as transitive dependencies. MDEPLOY-77 would require that all transitive dependencies also be deployed (as a locally-installed snap is not available to everyone else). Bottom line: we won't come to a happy resolution without cracking into Codehaus and making the enhancements we want. Also, I see the following problems with "taking all snapshots of all projects all the time": * New development in a particular project may (knowingly) break backwards-compatibility, and is not intended for integration with AS. * IT resources are limited and snapshots are cleared from the repo after 30 days * AS should be choosing which versions of which components it wants, not the other way around (ie. projects imposing its latest snap upon AS). S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171917#4171917 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171917

17 years, 7 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Improvements

by epbernard

well I was more thinking about an extreme version of that. A extreme CI. You take all snapshots of all projects all the time. So you see shit coming and you see when you break 95% of the app server. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171889#4171889 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171889

17 years, 7 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Improvements

by wolfc

You can only do continuous integration if the snapshot you're depending on doesn't have transitive dependencies which are snapshots themselves. For example AS -> ejb3-core SNAPSHOT -> ejb3-interceptors 0.1.0-SNAPSHOT -> ejb3-metadata 0.1.0-SNAPSHOT. If I were to deploy a new ejb3-metadata snapshot, which invalidates the ejb3-interceptors test suit, then AS is screwed. It should have been:ejb3-core SNAPSHOT -> ejb3-interceptors 0.1.0-20080821.010101-1 -> ejb3-metadata 0.1.0-20080820.010101-1. Now if I deploy a new ejb3-metadata it should automatically be picked up by interceptors which deploys after passing the test suite (or fails horrible). In both cases AS stays on the correct ejb3-metadata. We've discussed this in the past resulting in: http://jira.codehaus.org/browse/MDEPLOY-77. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171884#4171884 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171884

17 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: vfsmemory url problem

by mstruk

I fixed my buggy test :) Didn't cross my mind before to put the file directly on context root - not as a child, but as root itself. | URL dynamicClassRoot = new URL("vfsmemory", ".vfslink-test", ""); | MemoryFileFactory.createRoot(dynamicClassRoot); | | byte [] fileBytes = prepareFileContent(); | MemoryFileFactory.putFile(dynamicClassRoot, fileBytes); | Cheers, - marko View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171872#4171872 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171872

17 years, 7 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Improvements

by ALRubinger

The problem with snapshots, and the reason for their ban in AS component-matrix, is because a version of X.Y.Z-SNAPSHOT is not enough to uniquely identify a version to make a build reproducible: * By default, Maven local repo is reconciled only once/day to check for newer versions. * The notion of "newest" snapshot is defined by a timestamp, a property of the *publishing machine*. Rouge system clocks wreck havoc on all. * A developer may have installed a newer version locally than is available to all on snapshots.jboss.org However, take a look at a typical directory: http://snapshots.jboss.org/maven2/org/jboss/ejb3/jboss-ejb3-proxy/0.1.2-S... I'd like to test out explicitly specifying an extension in the version, ie: <version>0.1.2-20080818.031348-4</version> If Maven handles this case we may again put snaps up for integration testing in AS (using this format only), and hold off preparing a proper release until it's confirmed that the version we're testing is valid. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171833#4171833 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171833

17 years, 7 months

1
0
0 / 0

[Design of Management Features on JBoss] - ObjectName for clustered webapp session managers

by bstansberry＠jboss.com

The ObjectName we use to register a clustered webapp's session manager doesn't follow the same pattern as non-clustered Managers. Clustered webapp: jboss.web:WebModule=//localhost/http-sr,service=ClusterManager Non-clustered: jboss.web:host=localhost,path=/,type=Manager This will cause difficulties for ModClusterService, which has some beans that use JMX queries to gather load metrics. Plus, it just seems ugly. My intent is to have JBossCacheManager use ObjectNames that follow the non-clustered pattern. Tools only looking for clustered webapps can include the "Distributable" attribute in their query. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171831#4171831 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171831

17 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1423 Test case for @RemoteBinding

by ALRubinger

It's in the release of EJB3 Proxy 0.1.2. :) Nice job. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171829#4171829 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171829

17 years, 7 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJBTHREE-1454 Encapsulate Container infomation in TO/VO

by ALRubinger

"jaikiran" wrote : Do you foresee that this method might later require additional information about the container? If yes, do you want me to refactor it to accept the InvokableContext? I can't forsee any additional info needed there, but accepting InvokableContext is good for consistency I suppose. :) S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171828#4171828 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4171828

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