[Design of Messaging on JBoss (Messaging/JBoss)] - Need to have central wiki page where all different JBM deplo
by timfox
As we know, because we have to scope JBM in JBAS (until 4.2 that is) this makes JBM installation somewhat tricky.
The #1 theme in our support cases or forum issues seems to be people having problem with deploying their SARs/MDB containers etc scoped.
We should have a wiki page somewhere that covers all known deployment scenarios and clearly and simply in a step by step fashion explains where to put different jars, what config changes need to be made, what scripts need to be run.
This is currently a big source of confusion for users, and rightly so, there are some wiki pages and forums posts that go some way to explaining this but they are incomplete.
Deployment scenarios should include:
Standalone jms application client
JMS application client in JBAS, but with no messaging server in same AS
Servlet client in JBAS, but with no messaging server in same AS.
MDB client in JBAS, but with no messaging server in same AS.
EJB (non MDB) client in JBAS, but with no messaging server in same AS.
JMS application client in JBAS, with colocated messaging server.
Servlet client in JBAS, with colocated messaging server.
MDB client in JBAS with colocated messaging server.
EJB (non MDB) client in JBAS with colocated messaging server.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016316#4016316
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016316
19 years, 1 month
[Design of JBoss Labs] - Project.xml enhancements
by wrzep
Hello,
Below you can find my proposal affecting project.xml design.
After I started implementing project info edit view, I realized that using the current project.xml design is sometimes quite annoying ;-) That's why I'd like to introduce some changes.
What we've got now is the Project class representing the project.xml file in the CMS. There are fields that are mapped as lists since it's possible for them to occur more than one time in the project.xml file, but it seems to me it isn't really necessary. For instance, we allow multiple issue trackers, multiple repository locations to be assigned to one project. Example:
<project>
| ...
| <issue-tracker type="jira">http://jira.jboss.com/MySuperbProject</issue-tracker>
| <issue-tracker type="bugzilla">http://bugzilla.somewhere.com/MyEvenMoreSuperbProject</issue-tracker>
| ...
| </project>
This is mapped as the following method
protected List<IssueTracker> getIssueTrackers()
in the Project class.
I can imagine that some projects, sometimes might have more than one issue tracker. On the other hand, such a definition makes this property really difficult to use, cause:
1. We don't know which issue tracker is the project main one.
Let's say we want to have a link to the project issue tracker in the navigation. We don't know which one to choose.
2. It makes using Project bean more complicated. If every project had one issue tracker, the method would return just one IssueTracker bean. Easy to use, for example, in JSF ("#{project.issueTracker.link}") - you don't need to iterate. The same for the Java code.
That's why I'd vote for making it less general, but easier-to-use. With the current implementation I had to write a lot of useless lines of code dealing with lists.
Detailed proposal follows.
<project>
| ...
|
| <issue-tracker type="jira">http://jira.jboss.com/MySuperbProject</issue-tracker> <!-- one occurence, don't allow many -->
|
| <!-- was: multiple occurences of
| <repository type="SVN | ANONSVN | CVS | ANONCVS">url</repository> (even mixed CVS with ANONSVN!) -->
|
| <repo-type>SVN</repo-type>
| <anon-repo>http://anonsvn.jboss.com/MySuperbProjectRepo</anon-repo>
| <commiter-repo>http://svn.jboss.com/MySuperbProjectRepo</commiter-repo>
|
| <repo-monitor type="fisheye">fisheye url</repo-monitor> <!-- one occurence, don't allow many -->
|
| <!-- was: multiple occurences of
| <support-services type="support | training">http://jboss.com/GetSupportForThisProject</support-service> -->
|
| <support>http://jboss.com/GetSupportForThisProject</support>
| <training>http://jboss.com/training</training>
|
| ...
| </project>
This would simplify access to those attributes and make a lot of coding easier as we would get methods like:
Repository getAnonRepo();
| Repository getCommiterRepo();
| RepoMonitor getRepoMonitor();
| Training getTrainig();
instead of:
List<Repository> getRepositories();
| List<RepoMonitor> getRepoMonitors();
| protected List<SupportService> getSupportServices();
I'm aware of the fact that those are just details, but they seem to me as quite important details as they affect all projects and much of code ;-)
Comments are welcome :)
Cheers
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016027#4016027
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016027
19 years, 1 month