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

[Design the new POJO MicroContainer] - Re: Alternative vfs jar implementation

by dimitris＠jboss.org

So I've updated AS trunk to the latest VFS 2.0.0.Beta12 that Ales produced that contains the new alternative implementation. The problem that showed up immediately with the testsuite is that the jboss-minimal-tests fail. This is done by starting the jboss minimal config, then deploy a shutdown.sar and remove immediately. At undeploy time, shutdown.sar issues an exit and the server stop. Now, on Windows, if you try to remove the file before the reaper has run, the file cannot be removed, it is still locked. Then, if the reaper runs, the file gets unlocked so you can remove it, but on both windows and unix you get a: | 2008-06-02 21:12:55,140 WARN [org.jboss.test.jmx.shutdown.ExitOnShutdown] (HDScanner) Stopping failed jboss.test:name=ExitOnShutdown | java.lang.NoClassDefFoundError: org/jboss/test/jmx/shutdown/ExitOnShutdown$1 | at org.jboss.test.jmx.shutdown.ExitOnShutdown.stopService(ExitOnShutdown.java:48) | at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:328) | at org.jboss.system.ServiceMBeanSupport.stop(ServiceMBeanSupport.java:206) | The inner class org/jboss/test/jmx/shutdown/ExitOnShutdown$1 cannot be loaded anymore! After going in cyrcles all this time with the file locking issue, can we not replicate in VFS the functionality of good old jboss 4.x that it is known to work (i.e. point the classloader to copies in tmp, but at the same time don't do excessive file copying/unziping) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155143#4155143 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155143

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Need a Release of jboss-metadata 1.0.0.Beta16

by ALRubinger

OK; I've pushed the release of 1.0.0.Beta16. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155142#4155142 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155142

17 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: ending a process from other token than root token

by nizzy

anonymous wrote : probably an oversight in the xsd. can you verify that ? Was that directed at me Tom? I have had a look at the jpdl-3.2.xsd in the jbpm-jpdl.jar shipped with the jbpm-jpdl-suite-3.2.2 release and indeed there is no mention of this attribute in the schema. How do I get a more up-to-date schema? Cheers View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155116#4155116 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155116

17 years, 10 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Enforcer Restriction to Maven 2.0.9

by ALRubinger

Cool. Also, you can take a look at the EJB3 Build POM to see some other banned dependencies that Carlo has added (due to changed groupIds, etc). S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155115#4155115 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155115

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by bstansberry＠jboss.com

Thanks guys, for the input. :) My apologies, I opened this thread a couple hours before leaving on a trip where it turned out I had no chance for e-mail. I'll respond bit by bit as I digest. "adrian(a)jboss.org" wrote : | Short term for now, I'd just go with extending the hot deployment profile service to allow | some kind of barrier service like Brian describes to add/remove a sub-profile dynamically. | | I'm not sure it needs to be as complicated as Brian describes though? | i.e. messing around with dependencies | The hasingleton scanner should just respond to the elected/de-elected event | by adding/removing its profile to/from the profile service. This is essentially what's there now. Discovered last week that something is broken with it, but since it has a few flaws I wanted to focus on a more long-term replacement rather than just a quick fix. The flaws: 1) A scanner that populates the profile is a behavior of the basic profile service, but not of the full repository-based profile service. In the full version it's the DeploymentRepository impl itself that scans the filesystem for content. 2) The distinction betweens what's in a profile and how it's reflected in the runtime. If the profile service on a non-master node isn't aware at all of a set of deployments, those deployments can't be managed (e.g. some piece of metadata changed), at least not directly on that node. 3) Can't handle the fine-grained metadata driven approach you describe in your '@Singleton policy="DefaultPartitionSingleton"' example. Properly dealing with #2 and #3 could possibly be deferred; i.e. use a short term approach for 5.0.0. But AIUI, ability to use the full profile service is a requirement for 5.0.0 though, so I'd need to solve #1. On the farming thread Scott and I agreed last week that a clustered DeploymentRepository would need to have a clustered comm resource (JGroups Channel) available to it, so it's possible its internal scan logic could have the ability to respond to an elected/unelected event and add/remove sub-profile content. But that could end up being a fair amount of work and if the work will just be thrown away when I solve #2 and #3, I'm reluctant to do it that way. I need to better understand what Scott's driving at with the discussion of DESCRIBE, DESCRIBE_CLUSTERED, DESCRIBE_SINGLETON and how that solves the issue where we "(r)eally we don't want the unelected singleton beans to be exposed as available for installation as runtime components." Thanks, Ales for the links to the alias stuff; found where that's used. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155113#4155113 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155113

17 years, 10 months

1
0
0 / 0

[Design of JBoss Build System] - Re: Enforcer Restriction to Maven 2.0.9

by pgier

Ok, I think this is a good idea. I'll make the change this week to the AS parent pom. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155112#4155112 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155112

17 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: ending a process from other token than root token

by tom.baeyens＠jboss.com

probably an oversight in the xsd. can you verify that ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155110#4155110 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155110

17 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: ending a process from other token than root token

by nizzy

Hi, First time poster here. The behaviour you have been discussing is exactly what I require. However when I try to use the "end-complete-process" attribute in the end-state I get the exception org.jbpm.jpdl.JpdlException: [[ERROR] line 127: cvc-complex-type.3.2.2: Attribute 'end-complete-process' is not allowed to appear in element 'end-state' | <end-state name="Set-up Failed - ISAM ID" end-complete-process='true' /> I'm using JBPM 3.2.2, Is this a version thing? I must be doing something silly here! Cheers View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155109#4155109 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155109

17 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBMETA-44, ws annotation processing for references

by thomas.diesler＠jboss.com

yes, getAnnotatedElement() should be pointing to the client field View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155103#4155103 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155103

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Need a Release of jboss-metadata 1.0.0.Beta16

by alex.loubyansky＠jboss.com

These tests are for the functionality that is not fully implemented yet. I.e. JBoss50Creator. It's not used anywhere yet. So, we can release metadata as it currently is and complete the JBoss50Creator later. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155100#4155100 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155100

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