[Design the new POJO MicroContainer] - Federated resource visitor
by alesj
In order to impl Seam's tight integration with existing JBoss5/MC AnnotationEnvironment / ResourceVisitor (RV) pattern:
- https://jira.jboss.org/jira/browse/JBAS-6012
I need a sort of federated resource visitor - in order not to visit same resources many times.
e.g. with Seam deployment I would need to check for
- annotations (we already do this via GenericAnnotationRV)
- different configuration files; xmls, .properties, ...
hence requiring RV per resource.
I've hacked this FederatedVFSVR:
| protected boolean acceptRecurseFilter(VirtualFile file)
| {
| if (recurseFilters == null || recurseFilters.length == 0)
| return true;
|
| String path = determinePath(file);
| ResourceContext resource = new VFSResourceContext(file, path, getClassLoader());
| boolean accept = false;
| for (int j = 0; j < recurseFilters.length; j++)
| {
| recurseFlags[j] = recurseFilters[j] == null || recurseFilters[j].accepts(resource);
| if (recurseFlags[j]) // one accepts it
| accept = true;
| }
| return accept;
| }
|
| public void visit(VirtualFile file)
| {
| try
| {
| // We don't want directories
| if (file.isLeaf() == false)
| return;
|
| // Determine the resource name
| String path = determinePath(file);
| // go over the true flags
| for (int j = 0; j < visitors.length; j++)
| {
| if (recurseFlags == null || recurseFlags.length <= i || recurseFlags[j])
| {
| // Check for inclusions/exclusions
| if (includeds != null && includeds.length > j && includeds[j] != null && includeds[j].matchesResourcePath(path) == false)
| continue;
| if (excludeds != null && excludeds.length > j && excludeds[j] != null && excludeds[j].matchesResourcePath(path))
| continue;
|
| ResourceContext resource = new VFSResourceContext(file, path, getClassLoader());
| //Check the filter and visit
| if (filters == null || filters.length <= j || filters[j] == null || filters[j].accepts(resource))
| visitors[j].visit(resource);
| }
| }
| }
| catch (Exception e)
| {
| throw new Error("Error visiting " + file, e);
| }
| }
|
But I would need to somehow enable its usage in VFSClassLoaderPolicyModule,
where we actually 'hit' the Module.
Should I again expand Module::visit method,
to take multiple visitors, filters, recurseFilters?
Back-porting the old behavior to call the old non-federated single VFS VR.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179746#4179746
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179746
15 years, 6 months
[Design of JBoss Transaction Services] - Re: TransactionManager and AS' ServiceBindingManager
by jhalliday
In this week's exciting new episode: Jonathan breaks the AS cluster tests...
The clustering test mechanism does not use SBM, but rather uses the same default port set but with each server bound to a different IP using the '-b' option. This is fine for the JBossTS ports that bind to the same IP as the server.
The socketProcessId listener binds to localhost/127.0.0.1 regardless of the address used by the server. That's intentional - all instances on the same machine must use the same address to guarantee that the port number is uniq, which is what the service is trying to achieve.
When using the SBM with a fixed port value (4714) for the socketProccessId, the SBM offsets the value (4814, 4914, etc) for additional instances and you don't get a port conflict. When using the '-b' instead the same port number is used and things break.
Options:
- Use a value of '0', which tells the socketProcessId to use a random free port. Upside: probably the easiest fix, since it's a one line change in bindings.xml Downside: odd semantic change when 0 is offset (100, 200, etc) by the SBM - it's now fixed no longer random. The offset would also need to be greater that 1024 or you wind up trying to bind low numbered ports.
- Use the retry mechanism that tells socketProcessId to try consecutive ports counting up from the specified one until it finds a free one. This is disabled by default as I don't particularly like it. IMO if something is using the specified port that's an error that should be brought to the user's attention, not silently worked around. Upside: a relatively minor config change. Downside: the AS now uses an unpredictable set of ports, which some users won't like.
- Use an alternative implementation to get a uniq number. We have a file lock based one too for example. Getting the process ID for the JVM would also work, if there was some clean way to do it without resorting to native code.
- Change clustering tests to use the SBM. Of course this ignores the fact that customers may also want to run multiple servers using '-'b'. How common is that and will they tolerate having to make a config file change to do it?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179745#4179745
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179745
15 years, 6 months
[Design of JBoss jBPM] - Re: gwt-console in distribution
by kukeltje
Sorry, error in quoting... correct response below
"heiko.braun(a)jboss.com" wrote : Well, currently I don't see the need to leverage a framework like seam for the backend realization. GWT apps are more like fat clients with CRUD calls into the backend.
I know, but since there already is some nice functionality in seam for remoting (also to be used with GWT afaik, we could also leverage seam identity management, page security etc... and lots of other functionality (ok, not the pdf generation or excel or graphs or hibernate-validator like functionality, email templating, since that requires to use jsf and jBPM is going to use GWT). This was or is going to be all 'custom developed' in the current console or jBPM core.
"heiko.braun(a)jboss.com" wrote : No context/state management on server side necessary.As mentioned before, Seam does more imo... and it would mean (at least for you guys, since I do not work for JBoss) eat your own dogfood. Which would be good internal marketing I think, but that is just my opinion
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4179725#4179725
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4179725
15 years, 7 months