[JBoss-dev] [ jboss-Bugs-629145 ] ejb-link bug
Bugs item #629145, was opened at 2002-10-26 19:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=629145group_id=22866 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Stefan Wachter (stefanwachter) Assigned to: Christian Riege (lqd) Summary: ejb-link bug Initial Comment: JBoss V 3.0.3 I have an ear that contains an ejb.jar and web.war file. In the deployment descriptor of the web.war file (i.e. the web.xml) I have an ejb-ref to an EJB in the ejb.jar file. The spec says that the ejb-link element must contain the name of the jar-file followed by an '#' followed by the ejb-name of the referenced EJB: ejb-ref ejb-ref-nameejb/Converter/ejb-ref-name ejb-ref-typeSession/ejb-ref-type homede.xyz.converter.ConverterHome/home remotede.xyz.converter.Converter/remote ejb-linkejb.jar#Converter/ejb-link /ejb-ref Running the application causes an exception whereas the SUN reference implementation is happy with this link. If the ejb-link is changed to ejb-linkConverter/ejb-link, i.e. the jar is omitted. then the application also runs on JBoss. The attached ear demonstrates this behaviour. -- Comment By: Christian Riege (lqd) Date: 2003-01-24 09:02 Message: Logged In: YES user_id=176671 hi, sorry for the absence but i was rather busy. as no one seems to have complained in HEAD about the fix as of yet i will backport this. it will take until mid next week though. in the meantime, CVS access by sourceforge should have been fixed by now. -- Comment By: David Calvente (davidcalvente) Date: 2003-01-16 20:41 Message: Logged In: YES user_id=689193 Hi, I´ve the same problem, and tried 3.04 and also 3.2 RC1 and nothing changed. I´ve read that Christian Riege commited a fix, but I´m not able to connect to CVS. Please, coul anyone tell me when will this bug be fixed (wich release) and how can I use Christian´s path do go on till then... Thanks a lot David -- Comment By: Christian Riege (lqd) Date: 2002-12-12 17:53 Message: Logged In: YES user_id=176671 i have commited a fix for this in CVS HEAD. could you please re-check against CVS HEAD and tell me if it solves your problem; if it does I will backport it into 3.0 and 3.2 respectively. -- Comment By: Christian Riege (lqd) Date: 2002-11-27 15:41 Message: Logged In: YES user_id=176671 JBoss currently happily ignores the specified jar file. I will look into this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=629145group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-673928 ] Redeploy of exploded EAR doesn't work
Bugs item #673928, was opened at 2003-01-24 11:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=673928group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Rickard Öberg (rickardoberg) Assigned to: Nobody/Anonymous (nobody) Summary: Redeploy of exploded EAR doesn't work Initial Comment: I have deployed an exploded EAR (that in turn contains an exploded WAR file) file in JBoss 3.2RC1. The log output is: DEBUG [MainDeployer] Watching new file: file:/C:/projects/sitevision/build/deplo y/sitevision.ear/sitevision.war/ DEBUG [MainDeployer] Watching new file: file:/C:/projects/sitevision/build/deplo y/sitevision.ear/ --- This in itself is bad, because I don't want JBoss to watch the directories: it should watch the application and web.xml files! However, even if I touch the directories using Ant they are not redeployed. Nothing happens. The effect is that redeployment of exploded EAR files doesn't work at all. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=673928group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-673289 ] Deployment of Exploded EAR failing
Bugs item #673289, was opened at 2003-01-23 20:35
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=673289group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: J. Rhett Aultman (cuplan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Deployment of Exploded EAR failing
Initial Comment:
We have encountered a problem in deploying exploded
EAR files under JBoss 3.2rc1. We did not experience
this issue with the betas.
Below is the log from JBoss when deploying an
application first as an EAR file and then as an exploded
EAR (an EAR file's structure expanded out in directories
rather than being in a single file):
Loads fine when ear is not exploded.
14:14:00,562 INFO [MainDeployer] Starting deployment
of package: file:/C:/Documents and Settings/jmiller/My
Development/workspace/FCCIModel/deploy/fccimodel.ea
r
14:14:00,572 INFO [EARDeployer] Init J2EE
application: file:/C:/Documents and Settings/jmiller/My
Development/workspace/FCCIModel/deploy/fccimodel.ea
r
14:14:00,662 INFO [EJBDeployer] looking for nested
deployments in : file:/C:/java/jboss-
3.2.0RC1/server/default/tmp/deploy/C/Documents and
Settings/jmiller/My
Development/workspace/FCCIModel/deploy/fccimodel.ea
r/33.fccimodel.ear-contents/fccimodel.jar
14:14:00,852 INFO [EjbModule] Creating
14:14:00,902 INFO [EjbModule] Deploying
FCCIModelBean
14:14:00,942 INFO [StatelessSessionContainer]
Creating
14:14:00,952 INFO [StatelessSessionContainer]
Created
14:14:00,962 INFO [EjbModule] Created
14:14:00,962 INFO [EjbModule] Starting
14:14:00,962 INFO [StatelessSessionContainer]
Starting
14:14:01,012 INFO [StatelessSessionContainer] Started
14:14:01,022 INFO [EjbModule] Started
14:14:01,022 INFO [MainDeployer] Deployed package:
file:/C:/Documents and Settings/jmiller/My
Development/workspace/FCCIModel/deploy/fccimodel.ea
r
Exploded ear with exact same structure yields:
14:19:50,432 ERROR [URLDeploymentScanner] Failed
to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$
DeployedURL@f918c54c{ url=file:/C:/Documents and
Settings/jmiller/My
Development/workspace/FCCIModel/fccimodel.ear,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception
in init of file:/C:/Documents and Settings/jmiller/My
Development/workspace/FCCIModel/fccimodel.ear; -
nested throwable:
(org.jboss.deployment.DeploymentException: No META-
INF/application.xml found)
at org.jboss.deployment.MainDeployer.init
(MainDeployer.java:712)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:624)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:600)
at sun.reflect.GeneratedMethodAccessor21.invoke
(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invok
e(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:549)
at org.jboss.util.jmx.MBeanProxy.invoke
(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.
deploy(URLDeploymentScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.
scan(URLDeploymentScanner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScan
ner$ScannerThread.doScan
(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScan
ner.startService(AbstractDeploymentScanner.java:268)
at org.jboss.system.ServiceMBeanSupport.start
(ServiceMBeanSupport.java:197)
at sun.reflect.GeneratedMethodAccessor7.invoke
(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invok
e(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke
(ServiceController.java:957)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start
(ServiceController.java:388)
at sun.reflect.GeneratedMethodAccessor6.invoke
(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invok
e(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:549)
at org.jboss.util.jmx.MBeanProxy.invoke
(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start
(SARDeployer.java:299)
at org.jboss.deployment.MainDeployer.start
(MainDeployer.java:824)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:636)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:600)
[JBoss-dev] [ jboss-Bugs-673928 ] Redeploy of exploded EAR doesn't work
Bugs item #673928, was opened at 2003-01-24 12:55
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=673928group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rickard Öberg (rickardoberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Redeploy of exploded EAR doesn't work
Initial Comment:
I have deployed an exploded EAR (that in turn contains
an exploded WAR file) file in JBoss 3.2RC1. The log
output is:
DEBUG [MainDeployer] Watching new file:
file:/C:/projects/sitevision/build/deplo
y/sitevision.ear/sitevision.war/
DEBUG [MainDeployer] Watching new file:
file:/C:/projects/sitevision/build/deplo
y/sitevision.ear/
---
This in itself is bad, because I don't want JBoss to
watch the directories: it should watch the application
and web.xml files!
However, even if I touch the directories using Ant
they are not redeployed. Nothing happens.
The effect is that redeployment of exploded EAR files
doesn't work at all.
--
Comment By: Alexey Loubyansky (loubyansky)
Date: 2003-01-24 13:46
Message:
Logged In: YES
user_id=543482
There was a bug in 3.2 where the default (Sun's) protocols
handlers were used instead of JBoss' ones. There were two
problems with it:
- incorrect last modified date (as you see);
- opened files where locked on windows.
This was fixed.
As to the watching URLs, I think it's a logging mess. JBoss
really watches the file, not directory.
Here is the relevant snippet from EARDeployer:
// resolve the watch
if (di.url.getProtocol().equals(file))
{
File file = new File(di.url.getFile());
// If not directory we watch the package
if (!file.isDirectory()) {
di.watch = di.url;
}
// If directory we watch the xml files
else {
di.watch = new URL(di.url, META-INF/application.xml);
}
}
else
{
// We watch the top only, no directory support
di.watch = di.url;
}
But MainDeployer logs:
log.debug(Watching new file: + deployment.url);
Note: deployment.url instead of deployment.watch.
So, could you update your version and try again?
alex
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=673928group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-673928 ] Redeploy of exploded EAR doesn't work
Bugs item #673928, was opened at 2003-01-24 11:55
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=673928group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rickard Öberg (rickardoberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Redeploy of exploded EAR doesn't work
Initial Comment:
I have deployed an exploded EAR (that in turn contains
an exploded WAR file) file in JBoss 3.2RC1. The log
output is:
DEBUG [MainDeployer] Watching new file:
file:/C:/projects/sitevision/build/deplo
y/sitevision.ear/sitevision.war/
DEBUG [MainDeployer] Watching new file:
file:/C:/projects/sitevision/build/deplo
y/sitevision.ear/
---
This in itself is bad, because I don't want JBoss to
watch the directories: it should watch the application
and web.xml files!
However, even if I touch the directories using Ant
they are not redeployed. Nothing happens.
The effect is that redeployment of exploded EAR files
doesn't work at all.
--
Comment By: Rickard Öberg (rickardoberg)
Date: 2003-01-24 12:50
Message:
Logged In: YES
user_id=28931
Great, that would explain it. I'd really prefer to get a
dist, as it's been ages since I last downloaded JBoss from
CVS and built it. I have no time to figure out how to build
the JBoss/Tomcat distro. Is the fix available in any current
dist? If so I can get it from there.
--
Comment By: Alexey Loubyansky (loubyansky)
Date: 2003-01-24 12:46
Message:
Logged In: YES
user_id=543482
There was a bug in 3.2 where the default (Sun's) protocols
handlers were used instead of JBoss' ones. There were two
problems with it:
- incorrect last modified date (as you see);
- opened files where locked on windows.
This was fixed.
As to the watching URLs, I think it's a logging mess. JBoss
really watches the file, not directory.
Here is the relevant snippet from EARDeployer:
// resolve the watch
if (di.url.getProtocol().equals(file))
{
File file = new File(di.url.getFile());
// If not directory we watch the package
if (!file.isDirectory()) {
di.watch = di.url;
}
// If directory we watch the xml files
else {
di.watch = new URL(di.url, META-INF/application.xml);
}
}
else
{
// We watch the top only, no directory support
di.watch = di.url;
}
But MainDeployer logs:
log.debug(Watching new file: + deployment.url);
Note: deployment.url instead of deployment.watch.
So, could you update your version and try again?
alex
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=673928group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-673928 ] Redeploy of exploded EAR doesn't work
Bugs item #673928, was opened at 2003-01-24 12:55
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=673928group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rickard Öberg (rickardoberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Redeploy of exploded EAR doesn't work
Initial Comment:
I have deployed an exploded EAR (that in turn contains
an exploded WAR file) file in JBoss 3.2RC1. The log
output is:
DEBUG [MainDeployer] Watching new file:
file:/C:/projects/sitevision/build/deplo
y/sitevision.ear/sitevision.war/
DEBUG [MainDeployer] Watching new file:
file:/C:/projects/sitevision/build/deplo
y/sitevision.ear/
---
This in itself is bad, because I don't want JBoss to
watch the directories: it should watch the application
and web.xml files!
However, even if I touch the directories using Ant
they are not redeployed. Nothing happens.
The effect is that redeployment of exploded EAR files
doesn't work at all.
--
Comment By: Alexey Loubyansky (loubyansky)
Date: 2003-01-24 14:00
Message:
Logged In: YES
user_id=543482
Sorry, I don't really know whether the fix is in the binaries.
There is a readme file in catalina dir that explains how to build
it. It doesn't look that hard.
alex
--
Comment By: Rickard Öberg (rickardoberg)
Date: 2003-01-24 13:50
Message:
Logged In: YES
user_id=28931
Great, that would explain it. I'd really prefer to get a
dist, as it's been ages since I last downloaded JBoss from
CVS and built it. I have no time to figure out how to build
the JBoss/Tomcat distro. Is the fix available in any current
dist? If so I can get it from there.
--
Comment By: Alexey Loubyansky (loubyansky)
Date: 2003-01-24 13:46
Message:
Logged In: YES
user_id=543482
There was a bug in 3.2 where the default (Sun's) protocols
handlers were used instead of JBoss' ones. There were two
problems with it:
- incorrect last modified date (as you see);
- opened files where locked on windows.
This was fixed.
As to the watching URLs, I think it's a logging mess. JBoss
really watches the file, not directory.
Here is the relevant snippet from EARDeployer:
// resolve the watch
if (di.url.getProtocol().equals(file))
{
File file = new File(di.url.getFile());
// If not directory we watch the package
if (!file.isDirectory()) {
di.watch = di.url;
}
// If directory we watch the xml files
else {
di.watch = new URL(di.url, META-INF/application.xml);
}
}
else
{
// We watch the top only, no directory support
di.watch = di.url;
}
But MainDeployer logs:
log.debug(Watching new file: + deployment.url);
Note: deployment.url instead of deployment.watch.
So, could you update your version and try again?
alex
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=673928group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Can it be used at server startup instead of the jboss-service.xml, etc. files? i.e. can it create all Mbeans and apply all attributes value at runtime or can he only capture an instant snapshot of the current values? -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : mercredi, 22 janvier 2003 19:39 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service BTW, I realize that the name Master Configuration Service may be misleading. It only configures the JMX RW attributes, and isn't really intended as a fundamental architectural component, but rather as an optional tool and a POC for the flexibility of JMX. - Matt -Original Message- From: Matt Munz Sent: Wednesday, January 22, 2003 1:14 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Bill, I read the forum, and I'm not sure how this relates to MBean Persistence. Your examples seem to be AOP-specific. Could you give an example of what the integration of this stuff with JMX would be like (if that is what you intend)? - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 12:13 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service I am doing some things around MetaData and centralized configuration and configuration chains in AOP that I'd like to merge with the rest of JBoss. Please see the topic configuration and metadata in the AOP forum. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Wednesday, January 22, 2003 11:47 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Dain, I put this together with your use cases in mind. If possible, check it out, and let me know what you think. - Matt -Original Message- From: SourceForge.net [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 11:29 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Change Notes item #672538, was opened at 2003-01-22 11:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=67253 8group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Matthew Munz (mattmunz) Assigned to: Nobody/Anonymous (nobody) Summary: Master Configuration Service Initial Comment: A Service which writes and reads all of the JMX RW attributes to a single file in the Java Properties Format. I figured that this would be a good step on the road to an XML MBean Persistence engine. This service operates externally to the MBeans it persists. It is not really in line with the JMX spec, so it doesn't provide MBean Persistence in the way implied by the spec. Nonetheless, a snapshot of the server can be written and loaded quite easily. The details can be found in the documentation located under $jboss-head/varia/src/reources/master- config.sar/documentation . There are a few little details that should probably be ironed out, but for those that need MBean persistence today, this is a viable solution. The main audience for this tool is the system admin that does not use or prefer gui / html configuration tools. The use of the Properties file format is intentional, as it provides a more compact and readible interface when compared with the XML format. I'm not sure about the location of this code in the source tree, so I just put it in varia for now. I'd appreciate any ideas on a better place for it. - Matt Munz -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=67253 8group_id=22866 --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED]
[JBoss-dev] [ jboss-Bugs-673928 ] Redeploy of exploded EAR doesn't work
Bugs item #673928, was opened at 2003-01-24 11:55
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=673928group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rickard Öberg (rickardoberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Redeploy of exploded EAR doesn't work
Initial Comment:
I have deployed an exploded EAR (that in turn contains
an exploded WAR file) file in JBoss 3.2RC1. The log
output is:
DEBUG [MainDeployer] Watching new file:
file:/C:/projects/sitevision/build/deplo
y/sitevision.ear/sitevision.war/
DEBUG [MainDeployer] Watching new file:
file:/C:/projects/sitevision/build/deplo
y/sitevision.ear/
---
This in itself is bad, because I don't want JBoss to
watch the directories: it should watch the application
and web.xml files!
However, even if I touch the directories using Ant
they are not redeployed. Nothing happens.
The effect is that redeployment of exploded EAR files
doesn't work at all.
--
Comment By: Rickard Öberg (rickardoberg)
Date: 2003-01-24 14:31
Message:
Logged In: YES
user_id=28931
Adding -Djava.protocol.handler.pkgs=org.jboss.net.protocol
to JAVA_OPTS makes it work :-) Crude, but effective. Thanks
for the help!
--
Comment By: Alexey Loubyansky (loubyansky)
Date: 2003-01-24 13:00
Message:
Logged In: YES
user_id=543482
Sorry, I don't really know whether the fix is in the binaries.
There is a readme file in catalina dir that explains how to build
it. It doesn't look that hard.
alex
--
Comment By: Rickard Öberg (rickardoberg)
Date: 2003-01-24 12:50
Message:
Logged In: YES
user_id=28931
Great, that would explain it. I'd really prefer to get a
dist, as it's been ages since I last downloaded JBoss from
CVS and built it. I have no time to figure out how to build
the JBoss/Tomcat distro. Is the fix available in any current
dist? If so I can get it from there.
--
Comment By: Alexey Loubyansky (loubyansky)
Date: 2003-01-24 12:46
Message:
Logged In: YES
user_id=543482
There was a bug in 3.2 where the default (Sun's) protocols
handlers were used instead of JBoss' ones. There were two
problems with it:
- incorrect last modified date (as you see);
- opened files where locked on windows.
This was fixed.
As to the watching URLs, I think it's a logging mess. JBoss
really watches the file, not directory.
Here is the relevant snippet from EARDeployer:
// resolve the watch
if (di.url.getProtocol().equals(file))
{
File file = new File(di.url.getFile());
// If not directory we watch the package
if (!file.isDirectory()) {
di.watch = di.url;
}
// If directory we watch the xml files
else {
di.watch = new URL(di.url, META-INF/application.xml);
}
}
else
{
// We watch the top only, no directory support
di.watch = di.url;
}
But MainDeployer logs:
log.debug(Watching new file: + deployment.url);
Note: deployment.url instead of deployment.watch.
So, could you update your version and try again?
alex
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=673928group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-673928 ] Redeploy of exploded EAR doesn't work
Bugs item #673928, was opened at 2003-01-24 12:55
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=673928group_id=22866
Category: JBossServer
Group: v3.2
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Rickard Öberg (rickardoberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Redeploy of exploded EAR doesn't work
Initial Comment:
I have deployed an exploded EAR (that in turn contains
an exploded WAR file) file in JBoss 3.2RC1. The log
output is:
DEBUG [MainDeployer] Watching new file:
file:/C:/projects/sitevision/build/deplo
y/sitevision.ear/sitevision.war/
DEBUG [MainDeployer] Watching new file:
file:/C:/projects/sitevision/build/deplo
y/sitevision.ear/
---
This in itself is bad, because I don't want JBoss to
watch the directories: it should watch the application
and web.xml files!
However, even if I touch the directories using Ant
they are not redeployed. Nothing happens.
The effect is that redeployment of exploded EAR files
doesn't work at all.
--
Comment By: Rickard Öberg (rickardoberg)
Date: 2003-01-24 15:31
Message:
Logged In: YES
user_id=28931
Adding -Djava.protocol.handler.pkgs=org.jboss.net.protocol
to JAVA_OPTS makes it work :-) Crude, but effective. Thanks
for the help!
--
Comment By: Alexey Loubyansky (loubyansky)
Date: 2003-01-24 14:00
Message:
Logged In: YES
user_id=543482
Sorry, I don't really know whether the fix is in the binaries.
There is a readme file in catalina dir that explains how to build
it. It doesn't look that hard.
alex
--
Comment By: Rickard Öberg (rickardoberg)
Date: 2003-01-24 13:50
Message:
Logged In: YES
user_id=28931
Great, that would explain it. I'd really prefer to get a
dist, as it's been ages since I last downloaded JBoss from
CVS and built it. I have no time to figure out how to build
the JBoss/Tomcat distro. Is the fix available in any current
dist? If so I can get it from there.
--
Comment By: Alexey Loubyansky (loubyansky)
Date: 2003-01-24 13:46
Message:
Logged In: YES
user_id=543482
There was a bug in 3.2 where the default (Sun's) protocols
handlers were used instead of JBoss' ones. There were two
problems with it:
- incorrect last modified date (as you see);
- opened files where locked on windows.
This was fixed.
As to the watching URLs, I think it's a logging mess. JBoss
really watches the file, not directory.
Here is the relevant snippet from EARDeployer:
// resolve the watch
if (di.url.getProtocol().equals(file))
{
File file = new File(di.url.getFile());
// If not directory we watch the package
if (!file.isDirectory()) {
di.watch = di.url;
}
// If directory we watch the xml files
else {
di.watch = new URL(di.url, META-INF/application.xml);
}
}
else
{
// We watch the top only, no directory support
di.watch = di.url;
}
But MainDeployer logs:
log.debug(Watching new file: + deployment.url);
Note: deployment.url instead of deployment.watch.
So, could you update your version and try again?
alex
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=673928group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Sacha, No. Nothing fancy going on here. Just a quick one-off proof-of-concept deal. What it does is make text-file-based mbean persistence available today, in a format perhaps more amenable to vi hackers. It's pretty simple to use -- why don't you just drop it in deploy and try it out... Basically, it takes and loads snapshots. Simple and useable. I suppose it could be modified to do other things... What is wrong with the jboss-service.xml files? I'm curious -- What are you getting at? - Matt -Original Message- From: Sacha Labourey [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 8:00 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Can it be used at server startup instead of the jboss-service.xml, etc. files? i.e. can it create all Mbeans and apply all attributes value at runtime or can he only capture an instant snapshot of the current values? -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : mercredi, 22 janvier 2003 19:39 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service BTW, I realize that the name Master Configuration Service may be misleading. It only configures the JMX RW attributes, and isn't really intended as a fundamental architectural component, but rather as an optional tool and a POC for the flexibility of JMX. - Matt -Original Message- From: Matt Munz Sent: Wednesday, January 22, 2003 1:14 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Bill, I read the forum, and I'm not sure how this relates to MBean Persistence. Your examples seem to be AOP-specific. Could you give an example of what the integration of this stuff with JMX would be like (if that is what you intend)? - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 12:13 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service I am doing some things around MetaData and centralized configuration and configuration chains in AOP that I'd like to merge with the rest of JBoss. Please see the topic configuration and metadata in the AOP forum. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Wednesday, January 22, 2003 11:47 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Dain, I put this together with your use cases in mind. If possible, check it out, and let me know what you think. - Matt -Original Message- From: SourceForge.net [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 11:29 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Change Notes item #672538, was opened at 2003-01-22 11:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=67253 8group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Matthew Munz (mattmunz) Assigned to: Nobody/Anonymous (nobody) Summary: Master Configuration Service Initial Comment: A Service which writes and reads all of the JMX RW attributes to a single file in the Java Properties Format. I figured that this would be a good step on the road to an XML MBean Persistence engine. This service operates externally to the MBeans it persists. It is not really in line with the JMX spec, so it doesn't provide MBean Persistence in the way implied by the spec. Nonetheless, a snapshot of the server can be written and loaded quite easily. The details can be found in the documentation located under
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Title: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Oh, no, nothing wrong at all. It is just that while I can easily see an advantage to take a snapshot of a server config for future reference or analysis, re-loading a previous seems as hazardous to me because the configuration should really be applied when the mbeans are created, not afterwards because many settings would then have no effects at all (such as port numbers, etc.) Thank you. cheers, Sacha -Message d'origine-De: Matt Munz [mailto:[EMAIL PROTECTED]]De la part de Matt MunzEnvoyé: vendredi, 24 janvier 2003 15:35À: [EMAIL PROTECTED]Objet: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, No. Nothing fancy going on here. Just a quick one-off proof-of-concept deal. What it does is make text-file-based mbean persistence available today, in a format perhaps more amenable to vi hackers. It's pretty simple to use -- why don't you just drop it in deploy and try it out... Basically, it takes and loads snapshots. Simple and useable. I suppose it could be modified to do other things... What is wrong with the jboss-service.xml files? I'm curious -- What are you getting at? - Matt -Original Message- From: Sacha Labourey [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 8:00 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Can it be used at server startup instead of the jboss-service.xml, etc.files? i.e. can it create all Mbeans and apply all attributes value atruntime or can he "only" capture an instant snapshot of the current values? -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : mercredi, 22 janvier 2003 19:39 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service BTW, I realize that the name "Master Configuration Service" may be misleading. It only configures the JMX RW attributes, and isn't really intended as a fundamental architectural component, but rather as an optional tool and a POC for the flexibility of JMX. - Matt -Original Message- From: Matt Munz Sent: Wednesday, January 22, 2003 1:14 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Bill, I read the forum, and I'm not sure how this relates to MBean Persistence. Your examples seem to be AOP-specific. Could you give an example of what the integration of this stuff with JMX would be like (if that is what you intend)? - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 12:13 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service I am doing some things around MetaData and centralized configuration and configuration chains in AOP that I'd like to merge with the rest of JBoss. Please see the topic configuration and metadata in the AOP forum. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Wednesday, January 22, 2003 11:47 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration ServiceDain, I put this together with your use cases in mind. If possible, check it out, and let me know what you think. - Matt -Original Message- From: SourceForge.net [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 11:29 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Change Notes item #672538, was opened at 2003-01-22 11:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=67253 8group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Matthew Munz (mattmunz) Assigned to: Nobody/Anonymous (nobody) Summary: Master Configuration Service Initial Comment: A Service which writes and reads all of the JMX RW attributes to a single file in the Java Properties Format. I figured that this would be a good step on the road to an XML MBean Persistence engine. This service operates externally to the MBeans it persists. It is not really in line with the JMX spec, so it doesn't provide MBean Persistence in the way implied by the spec. Nonetheless, a "snapshot" of the server can be written and loaded quite easily. The details can be found in the documentation located under
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Sacha, I don't really understand. What good is a RW attribute if changing it has no effect? If this is really the case, then I think a lot of those RW attributes should be changed to RO. The whole idea of JMX is Management. The interface means something, right? - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Sacha Labourey Sent: Fri 1/24/2003 9:45 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Oh, no, nothing wrong at all. It is just that while I can easily see an advantage to take a snapshot of a server config for future reference or analysis, re-loading a previous seems as hazardous to me because the configuration should really be applied when the mbeans are created, not afterwards because many settings would then have no effects at all (such as port numbers, etc.) Thank you. cheers, Sacha -Message d'origine- De : Matt Munz [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : vendredi, 24 janvier 2003 15:35 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, No. Nothing fancy going on here. Just a quick one-off proof-of-concept deal. What it does is make text-file-based mbean persistence available today, in a format perhaps more amenable to vi hackers. It's pretty simple to use -- why don't you just drop it in deploy and try it out... Basically, it takes and loads snapshots. Simple and useable. I suppose it could be modified to do other things... What is wrong with the jboss-service.xml files? I'm curious -- What are you getting at? - Matt -Original Message- From: Sacha Labourey [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 8:00 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Can it be used at server startup instead of the jboss-service.xml, etc. files? i.e. can it create all Mbeans and apply all attributes value at runtime or can he only capture an instant snapshot of the current values? -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : mercredi, 22 janvier 2003 19:39 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service BTW, I realize that the name Master Configuration Service may be misleading. It only configures the JMX RW attributes, and isn't really intended as a fundamental architectural component, but rather as an optional tool and a POC for the flexibility of JMX. - Matt -Original Message- From: Matt Munz Sent: Wednesday, January 22, 2003 1:14 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Bill, I read the forum, and I'm not sure how this relates to MBean Persistence. Your examples seem to be AOP-specific. Could you give an example of what the integration of this stuff with JMX would be like (if that is what you intend)? - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 12:13 PM To: [EMAIL PROTECTED]
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Title: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Not exatly. Take a look at the Naming Service MBean for example. It has a Port and IPAddress RW attribute for example because when the MBean is started the following occurs: - an instance of the Naming Service class is created (new blabla()) - the attribute values found in jboss-service.xml for this mbean are assigned to the RW attributes of the Naming Service MBean - the service controller invokes create and then start on the MBean instance - inside the create/start methods, the Port/IPAddress attribute values are used to connect to the appropriate port Once this is done, changing the Port RW attribute will have *no* effect i.e. the naming service will not unbind/rebind with a new address/port. For this, you must stop the service, change the values and restart it. Do you follow me? Cheers, sacha -Message d'origine-De: Matt Munz [mailto:[EMAIL PROTECTED]]De la part de Matt MunzEnvoyé: vendredi, 24 janvier 2003 15:59À: [EMAIL PROTECTED]Objet: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, I don't really understand. What good is a RW attribute if changing it has no effect? If this is really the case, then I think a lot of those RW attributes should be changed to RO. The whole idea of JMX is Management. The interface means something, right? - Matt -Original Message- From: [EMAIL PROTECTED]on behalf ofSacha Labourey Sent: Fri 1/24/2003 9:45 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Oh, no, nothing wrong at all. It is just that while I can easily see an advantage to take a snapshot of a server config for future reference or analysis, re-loading a previous seems as hazardous to me because the configuration should really be applied when the mbeans are created, not afterwards because many settings would then have no effects at all (such as port numbers, etc.) Thank you. cheers, Sacha -Message d'origine-De: Matt Munz [mailto:[EMAIL PROTECTED]]De la part de Matt MunzEnvoyé: vendredi, 24 janvier 2003 15:35À: [EMAIL PROTECTED]Objet: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, No. Nothing fancy going on here. Just a quick one-off proof-of-concept deal. What it does is make text-file-based mbean persistence available today, in a format perhaps more amenable to vi hackers. It's pretty simple to use -- why don't you just drop it in deploy and try it out... Basically, it takes and loads snapshots. Simple and useable. I suppose it could be modified to do other things... What is wrong with the jboss-service.xml files? I'm curious -- What are you getting at? - Matt -Original Message- From: Sacha Labourey [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 8:00 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Can it be used at server startup instead of the jboss-service.xml, etc.files? i.e. can it create all Mbeans and apply all attributes value atruntime or can he "only" capture an instant snapshot of the current values? -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : mercredi, 22 janvier 2003 19:39 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service BTW, I realize that the name "Master Configuration Service" may be misleading. It only configures the JMX RW attributes, and isn't really intended as a fundamental architectural component, but rather as an optional tool and a POC for the flexibility of JMX. - Matt -Original Message- From: Matt Munz Sent: Wednesday, January 22, 2003 1:14 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Bill, I read the forum, and I'm not sure how this relates to MBean Persistence. Your examples seem to be AOP-specific. Could you give an example of what the integration of this stuff with JMX would be like (if that is what you intend)? - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 12:13 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service I am doing some
Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Your coupling the ability to change an attribute with triggering a restart of the service. You may need to change serveral attributes and then restart a service to achive the affect you want. If every setting of a RW attribute causes the service to restart it could be a mess. If I change the port on the JRMP/RMI invoker, what happens to all of the currently deployed EJBs? If these attribute are changed to RO, then the server does not even startup as we cannot apply *-service.xml attributes. JMX does not have a useable life cycle and dependency notion at this point so the interface simply defines what can be set. Itegrating how attribute changes trigger JBoss service life cycle states is not a trivial issue. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Matt Munz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 24, 2003 6:59 AM Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, I don't really understand. What good is a RW attribute if changing it has no effect? If this is really the case, then I think a lot of those RW attributes should be changed to RO. The whole idea of JMX is Management. The interface means something, right? - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Sacha Labourey Sent: Fri 1/24/2003 9:45 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Oh, no, nothing wrong at all. It is just that while I can easily see an advantage to take a snapshot of a server config for future reference or analysis, re-loading a previous seems as hazardous to me because the configuration should really be applied when the mbeans are created, not afterwards because many settings would then have no effects at all (such as port numbers, etc.) Thank you. cheers, Sacha -Message d'origine- De : Matt Munz [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : vendredi, 24 janvier 2003 15:35 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, No. Nothing fancy going on here. Just a quick one-off proof-of-concept deal. What it does is make text-file-based mbean persistence available today, in a format perhaps more amenable to vi hackers. It's pretty simple to use -- why don't you just drop it in deploy and try it out... Basically, it takes and loads snapshots. Simple and useable. I suppose it could be modified to do other things... What is wrong with the jboss-service.xml files? I'm curious -- What are you getting at? - Matt -Original Message- From: Sacha Labourey [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 8:00 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Can it be used at server startup instead of the jboss-service.xml, etc. files? i.e. can it create all Mbeans and apply all attributes value at runtime or can he only capture an instant snapshot of the current values? -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : mercredi, 22 janvier 2003 19:39 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service BTW, I realize that the name Master Configuration Service may be misleading. It only configures the JMX RW attributes, and isn't really intended as a fundamental architectural component, but rather as an optional tool and a POC for the flexibility of JMX. - Matt -Original Message- From: Matt Munz Sent: Wednesday, January 22, 2003 1:14 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Bill, I read the forum, and I'm not sure how this relates to MBean Persistence. Your examples seem to be AOP-specific. Could you give an example of what the integration of this stuff with JMX would be like (if that is what you intend)? - Matt -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 12:13 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service I am doing some things around MetaData and centralized configuration and configuration chains in AOP that I'd like to merge with the rest of JBoss. Please see the topic configuration and metadata in the AOP forum. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matt Munz Sent: Wednesday, January 22, 2003 11:47 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Dain, I put this together
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Sacha, I follow you fine. The RW attributes you describe should be RO. Another mechanism should be used to designate a default value. This (mis)use of the MBean interface results in an inconsistent view of the server configuration capabilities. It may be convenient to describe a write-once at a very-specific time attribute as RW, but this is fitting a round peg in a square hole (it may fit, but it rattles around a lot and could break as a result). What you need is an Object-creation descriptor that says pass these arguments to the constructor of object X. Then the value will be set *before* the object is loaded into the MBean server, and there is no need to name any attributes RW spuriously. I think that it is possible that the XMBean descriptor has something like this -- perhaps this is the best option. The take-home message here is that MBean Persistence is a cross-cutting concern. As such, I expect it to pull some skeletons out of the closet re: MBeans with inconsistent interfaces. - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Sacha Labourey Sent: Fri 1/24/2003 10:30 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Not exatly. Take a look at the Naming Service MBean for example. It has a Port and IPAddress RW attribute for example because when the MBean is started the following occurs: - an instance of the Naming Service class is created (new blabla()) - the attribute values found in jboss-service.xml for this mbean are assigned to the RW attributes of the Naming Service MBean - the service controller invokes create and then start on the MBean instance - inside the create/start methods, the Port/IPAddress attribute values are used to connect to the appropriate port Once this is done, changing the Port RW attribute will have *no* effect i.e. the naming service will not unbind/rebind with a new address/port. For this, you must stop the service, change the values and restart it. Do you follow me? Cheers, sacha -Message d'origine- De : Matt Munz [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : vendredi, 24 janvier 2003 15:59 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, I don't really understand. What good is a RW attribute if changing it has no effect? If this is really the case, then I think a lot of those RW attributes should be changed to RO. The whole idea of JMX is Management. The interface means something, right? - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Sacha Labourey Sent: Fri 1/24/2003 9:45 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Oh, no, nothing wrong at all. It is just that while I can easily see an advantage to take a snapshot of a server config for future reference or analysis, re-loading a previous seems as hazardous to me because the configuration should really be applied when the mbeans are created, not afterwards because many settings would then have no effects at all (such as port numbers, etc.) Thank you. cheers, Sacha -Message d'origine- De : Matt Munz [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : vendredi, 24 janvier 2003 15:35 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, No. Nothing fancy going on here. Just a quick one-off proof-of-concept deal. What it does is make text-file-based mbean persistence available today, in a format perhaps more amenable to vi hackers. It's pretty simple to use -- why don't you just drop it in deploy and try it out...
Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
On Friday, January 24, 2003, at 11:07 AM, Matt Munz wrote: Sacha, I follow you fine. The RW attributes you describe should be RO. Another mechanism should be used to designate a default value. This (mis)use of the MBean interface results in an inconsistent view of the server configuration capabilities. It may be convenient to describe a write-once at a very-specific time attribute as RW, but this is fitting a round peg in a square hole (it may fit, but it rattles around a lot and could break as a result). I think our current lifecycle based approach is quite workable as long as you use it as described in my previous post. As I understand it you are suggesting replacing the jboss lifecycle idea with the following: 1. All attributes that currently require lifecycle state changes should be made read only and set in the mbean constructor. 2. There should be some easy to use way to recreate an mbean with the same object name, some unchanged attributes, but new constructor arguments, at least as easy as the current stop-change-start technique. 3. No lifecycle methods. This might work, I haven't thought of any fatal problems with it. +: Currently most of our mbeans are probably insufficiently synchronized. By setting all arguments in the constructor, such problems could perhaps be reduced. -: This would require rewriting nearly every jboss mbean. I'd like to see more advantages before undertaking such an enormous project. david jencks What you need is an Object-creation descriptor that says pass these arguments to the constructor of object X. Then the value will be set *before* the object is loaded into the MBean server, and there is no need to name any attributes RW spuriously. I think that it is possible that the XMBean descriptor has something like this -- perhaps this is the best option. The take-home message here is that MBean Persistence is a cross-cutting concern. As such, I expect it to pull some skeletons out of the closet re: MBeans with inconsistent interfaces. - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Sacha Labourey Sent: Fri 1/24/2003 10:30 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Not exatly. Take a look at the Naming Service MBean for example. It has a Port and IPAddress RW attribute for example because when the MBean is started the following occurs: - an instance of the Naming Service class is created (new blabla()) - the attribute values found in jboss-service.xml for this mbean are assigned to the RW attributes of the Naming Service MBean - the service controller invokes create and then start on the MBean instance - inside the create/start methods, the Port/IPAddress attribute values are used to connect to the appropriate port Once this is done, changing the Port RW attribute will have *no* effect i.e. the naming service will not unbind/rebind with a new address/port. For this, you must stop the service, change the values and restart it. Do you follow me? Cheers, sacha -Message d'origine- De : Matt Munz [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : vendredi, 24 janvier 2003 15:59 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, I don't really understand. What good is a RW attribute if changing it has no effect? If this is really the case, then I think a lot of those RW attributes should be changed to RO. The whole idea of JMX is Management. The interface means something, right? - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Sacha Labourey Sent: Fri 1/24/2003 9:45 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Oh, no, nothing wrong at all. It is just that while I can easily see an advantage to take a snapshot of a server config for future reference or analysis, re-loading a previous seems as hazardous to me because the configuration should really be applied when the mbeans are created, not afterwards because many settings would then have no effects at all (such as port numbers, etc.) Thank you. cheers, Sacha -Message d'origine- De : Matt Munz [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : vendredi, 24 janvier 2003 15:35 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, No. Nothing fancy going on here. Just a quick one-off proof-of-concept deal. What it does is make text-file-based mbean persistence available today, in a format perhaps more amenable to vi hackers. It's pretty simple to use -- why don't you just drop it in deploy and try it out... Basically,
[JBoss-dev] [ jboss-Bugs-672331 ] jboss.xml DTD doesn't contain read-only method-level tags
Bugs item #672331, was opened at 2003-01-22 01:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=672331group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Nobody/Anonymous (nobody) Summary: jboss.xml DTD doesn't contain read-only method-level tags Initial Comment: jboss.xml DTD doesn't contain the description for the read-only tag we can set at the method-level (it is present for the bean-level though). This is most probably not present as well in Branch_3_2 and HEAD. -- Comment By: Scott M Stark (starksm) Date: 2003-01-24 08:51 Message: Logged In: YES user_id=175228 Well how is it that we have these elements parsed in BeanMetaData but do not have a single testcase for them? This is needed as well. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=672331group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
I'd like to see more advantages before undertaking such an enormous project. oh yes! This problem really involves all management parts i.e. how we want to be able to store the config, modify the config, have config repositories, etc. Furthermore, we need to take in account in this new design the really-missing-restart-feature which is not equivalent to the stop-start semantic. We must really implement the restart trick for 4.0 as it is one of the only way to cleanly implement the valve trick (block the valve for new invocations as we cycle the app/service). Cheers, sacha --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-447158 ] Problem with cascade-delete in CMP2.x
Bugs item #447158, was opened at 2001-08-02 12:42
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=447158group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Liam Magee (lmagee)
Assigned to: Dain Sundstrom (dsundstrom)
Summary: Problem with cascade-delete in CMP2.x
Initial Comment:
In the JDBCRemoveEntityCommand, the deletion of the
master record happens before any slave records. Is
this correct? I get the following error when removing
an EJB with relations:
javax.ejb.RemoveException: Could not remove 3
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro
mServer(StreamRemoteCall.java:245)
at sun.rmi.transport.StreamRemoteCall.executeCall
(StreamRemoteCall.java:220)
at sun.rmi.server.UnicastRef.invoke
(UnicastRef.java:122)
at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_
Stub.invoke(Unknown Source)
at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invo
keContainer(GenericProxy.java:362)
at
org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invok
e(EntityProxy.java:133)
at $Proxy1.remove(Unknown Source)
at com.jaccess.startup.ModelTest.init
(C:/factory/jaccess/src/com/jaccess/startup/ModelTest.j
ava:46)
at com.jaccess.startup.ModelTest.main
(C:/factory/jaccess/src/com/jaccess/startup/ModelTest.j
ava:19)
The server log shows:
[CMP,DEBUG] Remove command executing: DELETE FROM
PRODUCT WHERE PROD_ID=?
[CMP,DEBUG] Set parameter: index=1, jdbcType=INTEGER,
value=3
[CMP,DEBUG] interbase.interclient.SQLException:
[interclient][interbase] violation of FOREIGN KEY
constraint INTEG_50 on table PROJECT
It looks to me like records with the foreign key
should be removed first, to preserve referential
integrity, ie:
for(int i=0; icmrFields.length; i++) {
if(cmrFields[i].getMetaData().getRelatedRole
().isCascadeDelete()) {
Object oldRelation = oldRelationMap.get(cmrFields
[i]);
if(oldRelation instanceof Collection) {
Iterator oldValues = ((Collection)
oldRelation).iterator();
while(oldValues.hasNext()) {
EJBLocalObject oldValue = (EJBLocalObject)
oldValues.next();
oldValue.remove();
}
} else {
EJBLocalObject oldValue = (EJBLocalObject)
oldRelation;
oldValue.remove();
}
}
}
try {
jdbcExecute(context.getId());
} catch (Exception e) {
throw new RemoveException(Could not remove +
context.getId());
}
I've compiled and run this on my test case and it
works correctly.
--
Comment By: Adrian Price (adrianprice)
Date: 2003-01-24 16:58
Message:
Logged In: YES
user_id=580837
This bug has been fixed? I beg to differ. I have observed this
problem myself on JBoss 3.0.1 with Hypersonic SQLDB,
whilst attempting to use CMR cascade-delete. The database
schema I am using specifies foreign key constraints on the
owed entities.
It is not appropriate to null the FK fields (I can see that's
what's happening) if the ejb-relationship-role in ejb-jar.xml
contains the cascade-delete/ element; instead, the
container must physically DELETE the related entities
BEFORE attempting to delete the owner entity, in the SAME
TRANSACTION, to avoid the database throwing a constraint
violation. This does not appear to be happening correctly.
Furthermore, the nulling of the owned entities' FKs appears
to be occurring in a different transaction, because afterwards
their FKs are null, and the owner entity is still present, its
remove() transaction having been rolled back on account of
the RemoveException throw because of the FK constraint
SQLException thrown by the database.
FYI: these same entity beans work just fine on WebLogic-
7.0, so I am confident that my application code and database
schema are correct.
--
Comment By: Dain Sundstrom (dsundstrom)
Date: 2001-11-04 15:00
Message:
Logged In: YES
user_id=251431
It is required that the object on which remove was called
is removed before remove is cascaded to any relationhsips.
See section 10.3.4.2 Cascade-delete of the EJB 2.0 Final
Draft for more info.
The code was removing the entity to be delete from all
relationships by setting the fk fields to null, before
executing the remove. The problem was that the changes to
the related entities were not synchronized with the
database (i.e., no update statement was executed) before
the remove was executed.
Note: this bug was fixed on 2001/08/07.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=447158group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
[JBoss-dev] [ jboss-Bugs-447158 ] Problem with cascade-delete in CMP2.x
Bugs item #447158, was opened at 2001-08-02 12:42
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=447158group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Liam Magee (lmagee)
Assigned to: Dain Sundstrom (dsundstrom)
Summary: Problem with cascade-delete in CMP2.x
Initial Comment:
In the JDBCRemoveEntityCommand, the deletion of the
master record happens before any slave records. Is
this correct? I get the following error when removing
an EJB with relations:
javax.ejb.RemoveException: Could not remove 3
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro
mServer(StreamRemoteCall.java:245)
at sun.rmi.transport.StreamRemoteCall.executeCall
(StreamRemoteCall.java:220)
at sun.rmi.server.UnicastRef.invoke
(UnicastRef.java:122)
at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_
Stub.invoke(Unknown Source)
at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invo
keContainer(GenericProxy.java:362)
at
org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invok
e(EntityProxy.java:133)
at $Proxy1.remove(Unknown Source)
at com.jaccess.startup.ModelTest.init
(C:/factory/jaccess/src/com/jaccess/startup/ModelTest.j
ava:46)
at com.jaccess.startup.ModelTest.main
(C:/factory/jaccess/src/com/jaccess/startup/ModelTest.j
ava:19)
The server log shows:
[CMP,DEBUG] Remove command executing: DELETE FROM
PRODUCT WHERE PROD_ID=?
[CMP,DEBUG] Set parameter: index=1, jdbcType=INTEGER,
value=3
[CMP,DEBUG] interbase.interclient.SQLException:
[interclient][interbase] violation of FOREIGN KEY
constraint INTEG_50 on table PROJECT
It looks to me like records with the foreign key
should be removed first, to preserve referential
integrity, ie:
for(int i=0; icmrFields.length; i++) {
if(cmrFields[i].getMetaData().getRelatedRole
().isCascadeDelete()) {
Object oldRelation = oldRelationMap.get(cmrFields
[i]);
if(oldRelation instanceof Collection) {
Iterator oldValues = ((Collection)
oldRelation).iterator();
while(oldValues.hasNext()) {
EJBLocalObject oldValue = (EJBLocalObject)
oldValues.next();
oldValue.remove();
}
} else {
EJBLocalObject oldValue = (EJBLocalObject)
oldRelation;
oldValue.remove();
}
}
}
try {
jdbcExecute(context.getId());
} catch (Exception e) {
throw new RemoveException(Could not remove +
context.getId());
}
I've compiled and run this on my test case and it
works correctly.
--
Comment By: Adrian Price (adrianprice)
Date: 2003-01-24 17:18
Message:
Logged In: YES
user_id=580837
Having re-read the EJB 2.0 specification, I have concluded
that the CMR spec. itself is BROKEN. Why on earth would
the spec. designers force CMP implementors to use such a
grossly inefficient cascade delete algorithm? They're forcing
you to update the owned entities, then to delete the owner
entity, then to delete the owned entities that you've only just
updated. I just can't see a reason why one would not simply
delete ALL the owned entities with a single SQL DELETE
statement before deleting the owner entity - that is what you
would do in raw SQL.
And another thing - why didn't they (EJB2.0 spec. designers)
provide a means of telling the CMP container that the
DATABASE will handle cascade deletes?
--
Comment By: Adrian Price (adrianprice)
Date: 2003-01-24 16:58
Message:
Logged In: YES
user_id=580837
This bug has been fixed? I beg to differ. I have observed this
problem myself on JBoss 3.0.1 with Hypersonic SQLDB,
whilst attempting to use CMR cascade-delete. The database
schema I am using specifies foreign key constraints on the
owed entities.
It is not appropriate to null the FK fields (I can see that's
what's happening) if the ejb-relationship-role in ejb-jar.xml
contains the cascade-delete/ element; instead, the
container must physically DELETE the related entities
BEFORE attempting to delete the owner entity, in the SAME
TRANSACTION, to avoid the database throwing a constraint
violation. This does not appear to be happening correctly.
Furthermore, the nulling of the owned entities' FKs appears
to be occurring in a different transaction, because afterwards
their FKs are null, and the owner entity is still present, its
remove() transaction having been rolled back on account of
the RemoveException throw because of the FK constraint
SQLException thrown by the database.
FYI: these same entity beans work just fine on WebLogic-
7.0, so I am confident that my application code and database
schema are correct.
--
Comment By: Dain Sundstrom (dsundstrom)
Date: 2001-11-04 15:00
Message:
Logged In: YES
user_id=251431
It is required that the object on which remove was called
Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
On Friday, January 24, 2003, at 11:53 AM, Sacha Labourey wrote: I'd like to see more advantages before undertaking such an enormous project. oh yes! This problem really involves all management parts i.e. how we want to be able to store the config, modify the config, have config repositories, etc. Furthermore, we need to take in account in this new design the really-missing-restart-feature which is not equivalent to the stop-start semantic. Why not? We must really implement the restart trick for 4.0 as it is one of the only way to cleanly implement the valve trick (block the valve for new invocations as we cycle the app/service). I was planning to move the dependency logic from ServiceController to ServiceContext and make ServiceContext an mbean interceptor. It would also block calls when state was not started. If you change a set of attributes, it would consult the metadata to see what lifecycle state it must downgrade to, go to it, and go back to started. Do you see something wrong with this plan? david Cheers, sacha --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-447158 ] Problem with cascade-delete in CMP2.x
Bugs item #447158, was opened at 2001-08-02 15:42
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=447158group_id=22866
Category: JBossCMP
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Liam Magee (lmagee)
Assigned to: Dain Sundstrom (dsundstrom)
Summary: Problem with cascade-delete in CMP2.x
Initial Comment:
In the JDBCRemoveEntityCommand, the deletion of the
master record happens before any slave records. Is
this correct? I get the following error when removing
an EJB with relations:
javax.ejb.RemoveException: Could not remove 3
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFro
mServer(StreamRemoteCall.java:245)
at sun.rmi.transport.StreamRemoteCall.executeCall
(StreamRemoteCall.java:220)
at sun.rmi.server.UnicastRef.invoke
(UnicastRef.java:122)
at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_
Stub.invoke(Unknown Source)
at
org.jboss.ejb.plugins.jrmp.interfaces.GenericProxy.invo
keContainer(GenericProxy.java:362)
at
org.jboss.ejb.plugins.jrmp.interfaces.EntityProxy.invok
e(EntityProxy.java:133)
at $Proxy1.remove(Unknown Source)
at com.jaccess.startup.ModelTest.init
(C:/factory/jaccess/src/com/jaccess/startup/ModelTest.j
ava:46)
at com.jaccess.startup.ModelTest.main
(C:/factory/jaccess/src/com/jaccess/startup/ModelTest.j
ava:19)
The server log shows:
[CMP,DEBUG] Remove command executing: DELETE FROM
PRODUCT WHERE PROD_ID=?
[CMP,DEBUG] Set parameter: index=1, jdbcType=INTEGER,
value=3
[CMP,DEBUG] interbase.interclient.SQLException:
[interclient][interbase] violation of FOREIGN KEY
constraint INTEG_50 on table PROJECT
It looks to me like records with the foreign key
should be removed first, to preserve referential
integrity, ie:
for(int i=0; icmrFields.length; i++) {
if(cmrFields[i].getMetaData().getRelatedRole
().isCascadeDelete()) {
Object oldRelation = oldRelationMap.get(cmrFields
[i]);
if(oldRelation instanceof Collection) {
Iterator oldValues = ((Collection)
oldRelation).iterator();
while(oldValues.hasNext()) {
EJBLocalObject oldValue = (EJBLocalObject)
oldValues.next();
oldValue.remove();
}
} else {
EJBLocalObject oldValue = (EJBLocalObject)
oldRelation;
oldValue.remove();
}
}
}
try {
jdbcExecute(context.getId());
} catch (Exception e) {
throw new RemoveException(Could not remove +
context.getId());
}
I've compiled and run this on my test case and it
works correctly.
--
Comment By: Alexey Loubyansky (loubyansky)
Date: 2003-01-24 19:35
Message:
Logged In: YES
user_id=543482
We are going to compensate spec's faults. Stay tuned!
alex
--
Comment By: Adrian Price (adrianprice)
Date: 2003-01-24 19:18
Message:
Logged In: YES
user_id=580837
Having re-read the EJB 2.0 specification, I have concluded
that the CMR spec. itself is BROKEN. Why on earth would
the spec. designers force CMP implementors to use such a
grossly inefficient cascade delete algorithm? They're forcing
you to update the owned entities, then to delete the owner
entity, then to delete the owned entities that you've only just
updated. I just can't see a reason why one would not simply
delete ALL the owned entities with a single SQL DELETE
statement before deleting the owner entity - that is what you
would do in raw SQL.
And another thing - why didn't they (EJB2.0 spec. designers)
provide a means of telling the CMP container that the
DATABASE will handle cascade deletes?
--
Comment By: Adrian Price (adrianprice)
Date: 2003-01-24 18:58
Message:
Logged In: YES
user_id=580837
This bug has been fixed? I beg to differ. I have observed this
problem myself on JBoss 3.0.1 with Hypersonic SQLDB,
whilst attempting to use CMR cascade-delete. The database
schema I am using specifies foreign key constraints on the
owed entities.
It is not appropriate to null the FK fields (I can see that's
what's happening) if the ejb-relationship-role in ejb-jar.xml
contains the cascade-delete/ element; instead, the
container must physically DELETE the related entities
BEFORE attempting to delete the owner entity, in the SAME
TRANSACTION, to avoid the database throwing a constraint
violation. This does not appear to be happening correctly.
Furthermore, the nulling of the owned entities' FKs appears
to be occurring in a different transaction, because afterwards
their FKs are null, and the owner entity is still present, its
remove() transaction having been rolled back on account of
the RemoveException throw because of the FK constraint
SQLException thrown by the database.
FYI: these same entity beans work just fine on WebLogic-
7.0, so I am confident that my application code and database
schema are
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Hello David, oh yes! This problem really involves all management parts i.e. how we want to be able to store the config, modify the config, have config repositories, etc. Furthermore, we need to take in account in this new design the really-missing-restart-feature which is not equivalent to the stop-start semantic. Why not? because otherwise, when you are in the stop state, you don't know if it is a definitive stop (in which case you shouln't block the valve for example) or a temporary stop (in which case you may want to give a way to a service/application to provide some temporary state that the service controller can give it back once the service is restarted for example) We must really implement the restart trick for 4.0 as it is one of the only way to cleanly implement the valve trick (block the valve for new invocations as we cycle the app/service). I was planning to move the dependency logic from ServiceController to ServiceContext and make ServiceContext an mbean interceptor. It would also block calls when state was not started. If you change a set of attributes, it would consult the metadata to see what lifecycle state it must downgrade to, go to it, and go back to started. Do you see something wrong with this plan? Well, then you cannot update the list of the JMX interceptors as you cycle your service, right? Otherwise, how do you cycle the ServiceContext interceptor? At one point, independently of where do you manage that, I am pretty sure that you need a part of the system that thinks I do think in a specific way because it is a restart and not a definitive stop. You don't think so? Cheers, sachay --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-674167 ] JBoss 3.0.5 running with Compaq Java 1.4.0
Bugs item #674167, was opened at 2003-01-24 12:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=674167group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: John Stalker (jstalker) Assigned to: Nobody/Anonymous (nobody) Summary: JBoss 3.0.5 running with Compaq Java 1.4.0 Initial Comment: I downloaded the src for jboss using the 3_0_5 tag and built it (all went fine) using Compaq's Java 1.4.0 on an alpha: uname -a = OSF1 iridium V5.1 1885 alpha alpha. I then fired up the server, only changing a few port numbers in the config file and get this output: JBoss Bootstrap Environment JBOSS_HOME: /home/iridium/prodinfo/tools/jboss JAVA: /usr/opt/java140/bin/java JAVA_OPTS: -DSQENV=jstalker -Dprogram.name=run.sh CLASSPATH: /home/iridium/prodinfo/tools/jboss/bin/run.jar:/usr/opt/java140/lib/tools.jar run.sh: unused non-option argument: 12:36:51,284 INFO [Server] JBoss Release: JBoss-3.0.5 CVSTag=JBoss_3_0_5 12:36:51,335 INFO [Server] Home Dir: /usr/home/prodinfo/tools/jboss-3.0.5 12:36:51,339 INFO [Server] Home URL: file:/usr/home/prodinfo/tools/jboss-3.0.5/ 12:36:51,344 INFO [Server] Library URL: file:/usr/home/prodinfo/tools/jboss-3.0.5/lib/ 12:36:51,357 INFO [Server] Patch URL: null 12:36:51,358 INFO [Server] Server Name: jstalker 12:36:51,360 INFO [Server] Server Home Dir: /usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker 12:36:51,362 INFO [Server] Server Home URL: file:/usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker/ 12:36:51,365 INFO [Server] Server Data Dir: /usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker/db 12:36:51,366 INFO [Server] Server Temp Dir: /usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker/tmp 12:36:51,368 INFO [Server] Server Config URL: file:/usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker/conf/ 12:36:51,369 INFO [Server] Server Library URL: file:/usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker/lib/ 12:36:51,369 INFO [Server] Root Deployemnt Filename: jboss-service.xml 12:36:51,377 INFO [Server] Starting General Purpose Architecture (GPA)... 12:36:52,109 INFO [ServerInfo] Java version: 1.4.0,Compaq Computer Corp. 12:36:52,110 INFO [ServerInfo] Java VM: Fast VM 1.4.0-1,Compaq Computer Corp. 12:36:52,110 INFO [ServerInfo] OS-System: OSF1 V5.1,alpha 12:36:52,215 INFO [ServiceController] Controller MBean online 12:36:52,471 INFO [MainDeployer] Creating 12:36:52,540 INFO [MainDeployer] Created 12:36:52,546 INFO [MainDeployer] Starting 12:36:52,549 INFO [MainDeployer] Started 12:36:52,575 INFO [JARDeployer] Creating 12:36:52,576 INFO [JARDeployer] Created 12:36:52,580 INFO [JARDeployer] Starting 12:36:52,582 INFO [MainDeployer] Adding deployer: org.jboss.deployment.JARDeployer@80a3040 12:36:52,584 INFO [JARDeployer] Started 12:36:52,614 INFO [SARDeployer] Creating 12:36:52,615 INFO [SARDeployer] Created 12:36:52,617 INFO [SARDeployer] Starting 12:36:52,617 INFO [MainDeployer] Adding deployer: org.jboss.deployment.SARDeployer@80a72b9 12:36:52,652 INFO [SARDeployer] Started 12:36:52,652 INFO [Server] Core system initialized 12:36:52,660 INFO [MainDeployer] Starting deployment of package: file:/usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker/conf/jboss-service.xml Java stack overflow in make_native_call for method init 12:36:55,081 ERROR [MainDeployer] could not create deployment: file:/usr/home/prodinfo/tools/jboss-3.0.5/server/jstalker/conf/jboss-service.xml org.jboss.deployment.DeploymentException: instantiating org.jboss.varia.property.PropertyEditorManagerService failed: java.lang.StackOverflowError; - nested throwable: (RuntimeErrorException: instantiating org.jboss.varia.property.PropertyEditorManagerService failed: java.lang.StackOverflowError Cause: java.lang.StackOverflowError) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:153) at org.jboss.system.ServiceController.install(ServiceController.java:231) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy2.install(Unknown Source) at org.jboss.deployment.SARDeployer.create(SARDeployer.java:189) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:766) at
Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Logically a restart vs stop/start can make sense, but practically it may not depending on the service. The problem is a service has to be omniscient to understand how to transition old state to the new state and this can be nearly impossible if the service externalizes much of its functionality through customizable socket factories, etc. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 24, 2003 9:37 AM Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Well, then you cannot update the list of the JMX interceptors as you cycle your service, right? Otherwise, how do you cycle the ServiceContext interceptor? At one point, independently of where do you manage that, I am pretty sure that you need a part of the system that thinks I do think in a specific way because it is a restart and not a definitive stop. You don't think so? Cheers, sachay --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-670650 ] EJBVerifier20 PrimaryKey test bug
Bugs item #670650, was opened at 2003-01-19 05:38
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=670650group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Lutz Walter (luwasoft)
Assigned to: Scott M Stark (starksm)
Summary: EJBVerifier20 PrimaryKey test bug
Initial Comment:
Version JBoss 3.0.5(stable) and JBoss 3.2.0RC1
OS independent, JDK independent
The EJBVerifier20 does a missleading verification on
PrimaryKey's.
To verifiy if the PrimaryKeyClass has a suitable
implementation of the equals(Object other) method
(12.2.12.c) it does:
from EJBVerifier20.java
cls = classloader.loadClass(entity.getPrimaryKeyClass());
one = cls.newInstance();
two = cls.newInstance();
if( !one.equals(two) ) {
if( cmp ) {
fireSpecViolationEvent( entity,
new Section(10.6.13.c));
} else {
fireSpecViolationEvent( entity,
new Section(12.2.12.c));
}
Please correct me if i am wrong but as far as i know, a
uninitialized PrimaryKey should never equal to another,
even if the other is in the same uninitialized state.
So, this is not the right test to verify this.
In JBoss 3.0.5 this results only in some INFO
messages during deployment, in JBoss 3.2.0RC1 the
EJBDeployer does not deploy EJBs with those PKs that
fail this test
--
Comment By: Scott M Stark (starksm)
Date: 2003-01-24 10:18
Message:
Logged In: YES
user_id=175228
This should be a warning, not a failure. Two unitialized
primary keys should be in the same state and should be
equal generally as they represent the same object. This test
is a heuristic to check if the key equals is screwed up, but it
cannot be viewed as worthy of a failure if the two keys are not
equal.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=670650group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-671644 ] Deploy Directory is Write-Protecting Files
Bugs item #671644, was opened at 2003-01-21 00:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=671644group_id=22866 Category: JBossServer Group: v3.2 Status: Closed Resolution: Fixed Priority: 9 Submitted By: r clegg (rclegg1) Assigned to: Nobody/Anonymous (nobody) Summary: Deploy Directory is Write-Protecting Files Initial Comment: Windows 98 JRE 1.4.1 Jboss 3.2 RC1 download 14/1/03 Any file, eg xml, sar , ear, etc on the deploy directory is now being write-protected by windows when Jboss is running, jboss must be locking the files exclusively. Previous versions did not do this. Cannot re-deploy files without shutting down jboss. This is a BIG problem. -- Comment By: Alexey Loubyansky (loubyansky) Date: 2003-01-21 01:21 Message: Logged In: YES user_id=543482 This should be fixed in CVS version. alex -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=671644group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-670650 ] EJBVerifier20 PrimaryKey test bug
Bugs item #670650, was opened at 2003-01-19 05:38
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=670650group_id=22866
Category: JBossServer
Group: v3.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Lutz Walter (luwasoft)
Assigned to: Scott M Stark (starksm)
Summary: EJBVerifier20 PrimaryKey test bug
Initial Comment:
Version JBoss 3.0.5(stable) and JBoss 3.2.0RC1
OS independent, JDK independent
The EJBVerifier20 does a missleading verification on
PrimaryKey's.
To verifiy if the PrimaryKeyClass has a suitable
implementation of the equals(Object other) method
(12.2.12.c) it does:
from EJBVerifier20.java
cls = classloader.loadClass(entity.getPrimaryKeyClass());
one = cls.newInstance();
two = cls.newInstance();
if( !one.equals(two) ) {
if( cmp ) {
fireSpecViolationEvent( entity,
new Section(10.6.13.c));
} else {
fireSpecViolationEvent( entity,
new Section(12.2.12.c));
}
Please correct me if i am wrong but as far as i know, a
uninitialized PrimaryKey should never equal to another,
even if the other is in the same uninitialized state.
So, this is not the right test to verify this.
In JBoss 3.0.5 this results only in some INFO
messages during deployment, in JBoss 3.2.0RC1 the
EJBDeployer does not deploy EJBs with those PKs that
fail this test
--
Comment By: Scott M Stark (starksm)
Date: 2003-01-24 10:54
Message:
Logged In: YES
user_id=175228
Fixed for 3.0.6 and above.
--
Comment By: Scott M Stark (starksm)
Date: 2003-01-24 10:18
Message:
Logged In: YES
user_id=175228
This should be a warning, not a failure. Two unitialized
primary keys should be in the same state and should be
equal generally as they represent the same object. This test
is a heuristic to check if the key equals is screwed up, but it
cannot be viewed as worthy of a failure if the two keys are not
equal.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=670650group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Hi alls! I think that in the current service implementation the only way to change a mbean attribute is a restart of the service. Why does not implementing the java bean event model (property change co) in jmx... after all there is in the spec. I think that if I set a attribute to a mbean, the attribute must modify the behaviour of the service, if a dependent mbean need the feedback must listen to the attribute change event. If the service can not change the attribute it must send a exception. If a dependent service can not handle a attribute change must be send a request to a the ServiceController to be restarted or deactivated. Claudio -Original Message- From: Sacha Labourey [SMTP:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 7:14 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Yes, I agree, it is up to the service to say if it knows how to implement a restart, otherwise the service controller will simply execute the restart commands as a start/stop pair against the non-compliant service. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Scott M Stark Envoyé : vendredi, 24 janvier 2003 19:04 À : [EMAIL PROTECTED] Objet : Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Logically a restart vs stop/start can make sense, but practically it may not depending on the service. The problem is a service has to be omniscient to understand how to transition old state to the new state and this can be nearly impossible if the service externalizes much of its functionality through customizable socket factories, etc. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 24, 2003 9:37 AM Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Well, then you cannot update the list of the JMX interceptors as you cycle your service, right? Otherwise, how do you cycle the ServiceContext interceptor? At one point, independently of where do you manage that, I am pretty sure that you need a part of the system that thinks I do think in a specific way because it is a restart and not a definitive stop. You don't think so? Cheers, sachay --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-673409 ] Table existence test fails during deployment w/MS SQLSERVER
Bugs item #673409, was opened at 2003-01-23 22:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=673409group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: nash (kanagawa) Assigned to: Nobody/Anonymous (nobody) Summary: Table existence test fails during deployment w/MS SQLSERVER Initial Comment: Beans deploy correctly and can be created in the MS SQL datasource, but when a bean is altered and the jar re-deployed jboss doesn't detect the existing table and horks up the error below... OS: Windows XP JDK: 1.4.0_03 17:09:54,028 DEBUG [ChoiceEntity] Initializing CMP plugin for ChoiceEntity 17:09:54,038 DEBUG [QuestionEntity] Entity Exists SQL: SELECT COUNT(*) FROM QuestionEntity WHERE Id=? 17:09:54,048 DEBUG [QuestionEntity] Insert Entity SQL: INSERT INTO QuestionEntity (Id, Text) VALUES (?, ?) 17:09:54,058 DEBUG [QuestionEntity] Remove SQL: DELETE FROM QuestionEntity WHERE Id=? 17:09:54,078 DEBUG [QuestionEntity] Executing SQL: CREATE TABLE QuestionEntity (Id INTEGER NOT NULL, Text INTEGER NOT NULL, CONSTRAINT pk_QuestionEntity PRIMARY KEY (Id)) 17:09:54,178 DEBUG [QuestionEntity] Could not create table QuestionEntity 17:09:54,198 WARN [ServiceController] Problem starting service jboss.j2ee:jndiName=ejb/c1dbtest1/ChoiceEntity,service=EJB org.jboss.deployment.DeploymentException: Error while creating table; - nested throwable: (java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]There is already an object named 'QuestionEntity' in the database.) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.createTable(JDBCStart Command.java:175) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.execute(JDBCStartComm and.java:84) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.startStoreManager(JDB CStoreManager.java:457) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManage r.java:369) at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManag er.java:198) at org.jboss.ejb.EntityContainer.start(EntityContainer.java:376) at org.jboss.ejb.Container.invoke(Container.java:756) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1058) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl ler.java:978) at $Proxy5.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:398) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy31.start(Unknown Source) at org.jboss.ejb.EjbModule.startService(EjbModule.java:430) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1 65) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl ler.java:978) at $Proxy5.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:398) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy11.start(Unknown Source) at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:395) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:807) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:621) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:585) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at
[JBoss-dev] Mail Filter?
I sent 3 messages to this list since 11:50 EST, but they haven't appeared in my inbox. Did anyone else get them? None had attachments -- is there some sort of filter in effect? - Matt N¬HSDMéX¬²'²Þu¼¢êÜxZ+á'µêé®+ Øþ .)îÅj+Ô¨ëax6I硶Úÿ 0½«(~Üç(è²Ç^½éh¦g§¶f¢)à+-%º,±×¯zZ)éí+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèþ6è²Ç^½éh¦g§
FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
this one didn't make it either... -Original Message- From: Matt Munz Sent: Fri 1/24/2003 12:18 PM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service David, If you will, take a step back with me. Think JMX and not JBoss-JMX. You are writing a tool to do generic operations on MBeans. This is the purpose of JMX in the first place. Your tool encounters a RW attribute. What assumptions can be made, reasonably? Here are my assumptions: 1. get the value of the attribute and store it in an object. Do not modify the object. Set the value of the attribute to the object. No error will occur. 2. set the attribute to a given value that is not equivalent to the current value. The behavior / state of the MBean will change in a meaningful way. Does the JMX spec enforce these? Perhaps not. Is it nevertheless reasonable to expect this behavior? I think so. Neither of these assumptions are upheld, however, in the current use of MBeans in JBoss. I realize that re-writing mbeans might cause pain for the project. I'm not suggesting that it should even be done, necessarily, at least not right away. I am, however, trying to reconcile the notion of a RW attribute where writing the value has no effect. Can this be explained simply? BTW, I don't see how the lifecycle is related to this particular issue. Perhaps you could explain this in more depth? - Matt -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 11:44 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service On Friday, January 24, 2003, at 11:07 AM, Matt Munz wrote: Sacha, I follow you fine. The RW attributes you describe should be RO. Another mechanism should be used to designate a default value. This (mis)use of the MBean interface results in an inconsistent view of the server configuration capabilities. It may be convenient to describe a write-once at a very-specific time attribute as RW, but this is fitting a round peg in a square hole (it may fit, but it rattles around a lot and could break as a result). I think our current lifecycle based approach is quite workable as long as you use it as described in my previous post. As I understand it you are suggesting replacing the jboss lifecycle idea with the following: 1. All attributes that currently require lifecycle state changes should be made read only and set in the mbean constructor. 2. There should be some easy to use way to recreate an mbean with the same object name, some unchanged attributes, but new constructor arguments, at least as easy as the current stop-change-start technique. 3. No lifecycle methods. This might work, I haven't thought of any fatal problems with it. +: Currently most of our mbeans are probably insufficiently synchronized. By setting all arguments in the constructor, such problems could perhaps be reduced. -: This would require rewriting nearly every jboss mbean. I'd like to see more advantages before undertaking such an enormous project. david jencks What you need is an Object-creation descriptor that says pass these arguments to the constructor of object X. Then the value will be set *before* the object is loaded into the MBean server, and there is no need to name any attributes RW spuriously. I think that it is possible that the XMBean descriptor has something like this -- perhaps this is the best option. The take-home message here is that MBean Persistence is a cross-cutting concern. As such, I expect it to pull some skeletons out of the closet re: MBeans with
Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Problem one if focusing on JMX over JBoss-JMX. The order is JBoss-JMX and then JMX generically. Twiddling attributes is an operation indepedent of restarting a service and if you don't agree with that then we are at a viewpoint impass. Setting a RW attribute has an effect. Its just not the effect you are looking for so either get on board and work within the service life cycle or go play in your JMX sandbox. Scream and shout about the purity of RW JMX attributes all you want, I don't buy it. Services with exposure of their attribute via JMX with their attendent life cycle management comes first. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Matt Munz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 24, 2003 12:23 PM Subject: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service this one didn't make it either... -Original Message- From: Matt Munz Sent: Fri 1/24/2003 12:18 PM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service David, If you will, take a step back with me. Think JMX and not JBoss-JMX. You are writing a tool to do generic operations on MBeans. This is the purpose of JMX in the first place. Your tool encounters a RW attribute. What assumptions can be made, reasonably? Here are my assumptions: 1. get the value of the attribute and store it in an object. Do not modify the object. Set the value of the attribute to the object. No error will occur. 2. set the attribute to a given value that is not equivalent to the current value. The behavior / state of the MBean will change in a meaningful way. Does the JMX spec enforce these? Perhaps not. Is it nevertheless reasonable to expect this behavior? I think so. Neither of these assumptions are upheld, however, in the current use of MBeans in JBoss. I realize that re-writing mbeans might cause pain for the project. I'm not suggesting that it should even be done, necessarily, at least not right away. I am, however, trying to reconcile the notion of a RW attribute where writing the value has no effect. Can this be explained simply? BTW, I don't see how the lifecycle is related to this particular issue. Perhaps you could explain this in more depth? - Matt --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
While I'm sure what you are proposing can be made to work, it would be a really big redesign of how mbeans are thought of in jboss. Something you can do today, in just a few minutes, and will make your proposal work with jboss as it is currently written is to use the service lifecycle methods as I outlined. david On Friday, January 24, 2003, at 03:24 PM, Matt Munz wrote: The third message that didn't make it the first time... -Original Message- From: Matt Munz Sent: Fri 1/24/2003 11:51 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service David, This sounds good, but is it possible to KIS? I think that interrelated attributes can be avoided in most cases. For the exceptional cases, we could provide a mechanism for declaring an order in which the attributes on a given bean should be set. As for inter-Bean dependencies, I suppose this is what the Notification API is for. The MBean interface will never be able to show the multitude of complex behaviors that an Object can present. What about the methods setValueButOnlyIfTodayIsTuesday(Object value) or setValueButOnlyIfValueFooOnMBeanBarIsAlsoSet(Object value). JMX, as it is, is nice and simple. The lifecycle feature might help, though--I'm on the fence. This is one of my beefs with generalized architectures -- it is so easy to think up ways to break the system! - Matt -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 10:52 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service JMX lacks a service lifecycle, which IMO is needed for this to make sense. For most jboss mbeans with attributes like port number etc, changing the attribute value will have an effect if you: stop change attribute values start Often there are several interrelated attributes so going through the lifecycle on an individual attribute change doesn't make sense. There is an unimplemented feature described in the xmbean dtd where you specify for an attribute what state of service lifecycle you need to go to when you change an attribute. The idea is if you call setAttributes() some interceptors should bring the lifecycle state to the least started level required of any attribute in the list. For your master configuration feature, I think for each mbean calling stop destroy set attributes create start will work. We will probably find plenty of bugs in lots of mbeans whose lifecycle is broken: fixing these will greatly improve jboss's stability IMO. david jencks On Friday, January 24, 2003, at 09:59 AM, Matt Munz wrote: Sacha, I don't really understand. What good is a RW attribute if changing it has no effect? If this is really the case, then I think a lot of those RW attributes should be changed to RO. The whole idea of JMX is Management. The interface means something, right? - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Sacha Labourey Sent: Fri 1/24/2003 9:45 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Oh, no, nothing wrong at all. It is just that while I can easily see an advantage to take a snapshot of a server config for future reference or analysis, re-loading a previous seems as hazardous to me because the configuration should really be applied when the mbeans are created, not afterwards because many settings would then have no effects at all (such as port numbers, etc.) Thank you. cheers, Sacha -Message d'origine- De : Matt Munz [mailto:[EMAIL PROTECTED]]De la part de Matt Munz Envoyé : vendredi, 24 janvier 2003 15:35 À : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Sacha, No. Nothing fancy going on here. Just a quick one-off proof-of-concept deal. What it does is make text-file-based mbean persistence available today, in a format perhaps more amenable to vi hackers. It's pretty simple to use -- why don't you just drop it in deploy and try it out... Basically, it takes and loads snapshots. Simple and useable. I suppose it could be modified to do other things... What is wrong with the jboss-service.xml files? I'm curious -- What are you getting at? - Matt -Original Message- From: Sacha Labourey [mailto:[EMAIL PROTECTED]]
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 24-January-2003
JBoss daily test results SUMMARY Number of tests run: 1010 Successful tests: 1006 Errors:3 Failures: 1 [time of test: 2003-01-24.12-05 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.3] See http://users.jboss.org/~starksm/Branch_3_0/2003-01-24.12-05 for details of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: CircularityUnitTestCase Test:testLoading(org.jboss.test.classloader.test.CircularityUnitTestCase) Type:error Exception: javax.management.RuntimeMBeanException Message: RuntimeException in MBean operation 'testLoading()' - Suite: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
On Friday, January 24, 2003, at 03:23 PM, Matt Munz wrote: this one didn't make it either... -Original Message- From: Matt Munz Sent: Fri 1/24/2003 12:18 PM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service David, If you will, take a step back with me. Think JMX and not JBoss-JMX. You are writing a tool to do generic operations on MBeans. This is the purpose of JMX in the first place. Your tool encounters a RW attribute. What assumptions can be made, reasonably? Here are my assumptions: 1. get the value of the attribute and store it in an object. Do not modify the object. Set the value of the attribute to the object. No error will occur. 2. set the attribute to a given value that is not equivalent to the current value. The behavior / state of the MBean will change in a meaningful way. Does the JMX spec enforce these? Perhaps not. Is it nevertheless reasonable to expect this behavior? I think so. Neither of these assumptions are upheld, however, in the current use of MBeans in JBoss. I realize that re-writing mbeans might cause pain for the project. I'm not suggesting that it should even be done, necessarily, at least not right away. I am, however, trying to reconcile the notion of a RW attribute where writing the value has no effect. Can this be explained simply? BTW, I don't see how the lifecycle is related to this particular issue. Perhaps you could explain this in more depth? In all the mbeans I have written and seen in jboss, aside from egregious bugs, if setting an attribute doesn't have an immediate effect, it does have the desired effect if you run through the service lifecycle (usually stop, start, occasionally stop, destroy, create, start). My view is that mbeans in jboss can take advantage of the service lifecycle. If you don't want to, make all your attribute changes have their effects immediately. All our mbeans are pretty much jboss specific and most heavily use the service lifecycle. They just won't run without it. I still think it is a really convenient extension to vanilla jmx and don't see why we should replace it. david jencks - Matt -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED]] Sent: Fri 1/24/2003 11:44 AM To: [EMAIL PROTECTED] Cc: Subject: Re: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service On Friday, January 24, 2003, at 11:07 AM, Matt Munz wrote: Sacha, I follow you fine. The RW attributes you describe should be RO. Another mechanism should be used to designate a default value. This (mis)use of the MBean interface results in an inconsistent view of the server configuration capabilities. It may be convenient to describe a write-once at a very-specific time attribute as RW, but this is fitting a round peg in a square hole (it may fit, but it rattles around a lot and could break as a result). I think our current lifecycle based approach is quite workable as long as you use it as described in my previous post. As I understand it you are suggesting replacing the jboss lifecycle idea with the following: 1. All attributes that currently require lifecycle state changes should be made read only and set in the mbean constructor. 2. There should be some easy to use way to recreate an mbean with the same object name, some unchanged attributes, but new constructor arguments, at least as easy as the current stop-change-start technique. 3. No lifecycle methods. This might work, I haven't thought of any fatal problems with it. +: Currently most of our mbeans are probably insufficiently synchronized. By setting all arguments in the constructor, such problems could perhaps be reduced. -: This would require rewriting nearly every jboss mbean. I'd like to see more advantages before undertaking such an enormous project. david jencks What you need is an Object-creation descriptor that says pass these arguments to the constructor of object X. Then the value will be set *before* the object is loaded into the MBean server, and there is no need to name any attributes RW spuriously. I think that it is possible that the XMBean descriptor has something like this -- perhaps this is the best option. The take-home message here is that MBean Persistence is a cross-cutting concern. As such, I expect it to pull some skeletons out of the closet re: MBeans with inconsistent interfaces. - Matt -Original Message- From: [EMAIL PROTECTED] on behalf of Sacha Labourey Sent: Fri 1/24/2003 10:30 AM To: [EMAIL PROTECTED] Cc: Subject: RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service Not exatly. Take a
[JBoss-dev] [ jboss-Bugs-673409 ] Table existence test fails during deployment w/MS SQLSERVER
Bugs item #673409, was opened at 2003-01-23 22:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=673409group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Closed Resolution: Invalid Priority: 5 Submitted By: nash (kanagawa) Assigned to: Nobody/Anonymous (nobody) Summary: Table existence test fails during deployment w/MS SQLSERVER Initial Comment: Beans deploy correctly and can be created in the MS SQL datasource, but when a bean is altered and the jar re-deployed jboss doesn't detect the existing table and horks up the error below... OS: Windows XP JDK: 1.4.0_03 17:09:54,028 DEBUG [ChoiceEntity] Initializing CMP plugin for ChoiceEntity 17:09:54,038 DEBUG [QuestionEntity] Entity Exists SQL: SELECT COUNT(*) FROM QuestionEntity WHERE Id=? 17:09:54,048 DEBUG [QuestionEntity] Insert Entity SQL: INSERT INTO QuestionEntity (Id, Text) VALUES (?, ?) 17:09:54,058 DEBUG [QuestionEntity] Remove SQL: DELETE FROM QuestionEntity WHERE Id=? 17:09:54,078 DEBUG [QuestionEntity] Executing SQL: CREATE TABLE QuestionEntity (Id INTEGER NOT NULL, Text INTEGER NOT NULL, CONSTRAINT pk_QuestionEntity PRIMARY KEY (Id)) 17:09:54,178 DEBUG [QuestionEntity] Could not create table QuestionEntity 17:09:54,198 WARN [ServiceController] Problem starting service jboss.j2ee:jndiName=ejb/c1dbtest1/ChoiceEntity,service=EJB org.jboss.deployment.DeploymentException: Error while creating table; - nested throwable: (java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]There is already an object named 'QuestionEntity' in the database.) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.createTable(JDBCStart Command.java:175) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.execute(JDBCStartComm and.java:84) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.startStoreManager(JDB CStoreManager.java:457) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManage r.java:369) at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManag er.java:198) at org.jboss.ejb.EntityContainer.start(EntityContainer.java:376) at org.jboss.ejb.Container.invoke(Container.java:756) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1058) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl ler.java:978) at $Proxy5.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:398) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy31.start(Unknown Source) at org.jboss.ejb.EjbModule.startService(EjbModule.java:430) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1 65) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl ler.java:978) at $Proxy5.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:398) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy11.start(Unknown Source) at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:395) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:807) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:621) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:585) at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at
RE: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Scott,
Email is bad format for emoting -- intent is often misinterpreted. I sincerely hope
that I have not offended anyone. This is never my intent.
I don't understand. I don't understand how the RW attribute issue relates to the
service lifecycle. I am not being critical, I am not being coy. I am sure that you
are right and I am wrong, but I don't know why. If you can spare the time, please
elaborate on this issue.
Twiddling attributes is an operation indepedent of restarting
a service and if you don't agree with that then we are at a viewpoint impass.
I just don't understand what this means. I have no intent of restarting a service. I
am not talking about restarting services. I am talking about the MBean interface.
David brought up the service lifecycle. I barely know what the service lifecycle is.
Could you please elaborate on this issue?
Setting
a RW attribute has an effect. Its just not the effect you are looking for so either
get
on board and work within the service life cycle or go play in your JMX sandbox.
setFoo(Object newFoo) { } /** this is an effect? */
Let me reiterate that I am not being critical, I am not telling anyone what to do, and
I am here to learn.
JBoss is great. The JBoss developers are awesome. It is a privelege to be a part of
this discussion in the first place.
- Matt Munz
Apelon, Inc.
winmail.dat
RE: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
David,
We are miscommunicating.
In all the mbeans I have written and seen in jboss, aside from
egregious bugs, if setting an attribute doesn't have an immediate
effect, it does have the desired effect if you run through the service
lifecycle (usually stop, start, occasionally stop, destroy, create,
start). My view is that mbeans in jboss can take advantage of the
service lifecycle. If you don't want to, make all your attribute
changes have their effects immediately. All our mbeans are pretty much
jboss specific and most heavily use the service lifecycle. They just
won't run without it. I still think it is a really convenient
extension to vanilla jmx and don't see why we should replace it.
I barely know what the service lifecycle is. I have not used it. I am not
arguing to replace it. I never said that. You said that.
How do I set an attribute correctly, step by step, for a Bean that uses the
service lifecycle?
It helps me to use a state metaphor when considering lifecycle issues. It
sounds like there are several states a lifecycle-oriented bean can be in: destroyed,
created, running. In which state is it safe to set RW attributes on
lifecycle-oriented beans?
Is the following the appropriate way to set values on a lifecycle-oriented
bean (pseudo-code)?
if(bean.isLifecycleOriented())
{
if(bean.isRunning())
{
bean.stop();
}
bean.setAttribute(newValue);
bean.start();
}
I'm here to learn :)
- Matt
N¬HSDMéX¬²'²Þu¼¢êÜxZ+á'µêé®+ Øþ .)îÅj+Ô¨ëax6I硶Úÿ
0½«(~Üç(è²Ç^½éh¦g§¶f¢)à+-%º,±×¯zZ)éí+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèþ6è²Ç^½éh¦g§
[JBoss-dev] [ jboss-Bugs-672975 ] MEMBER OF generates inner joins
Bugs item #672975, was opened at 2003-01-23 01:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=672975group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: Accepted Priority: 5 Submitted By: Alexei Yudichev (sflexus) Assigned to: Jeremy Boynes (jboynes) Summary: MEMBER OF generates inner joins Initial Comment: == This is a bug. Please file a bug report at sourceforge. MEMBER OF should be generating a sub select or a left join. This is simmilar to the IS NULL bug we recently fixed. -dain == SELECT OBJECT(c) FROM StoreCategory c, Partner p WHERE c.id=?1 AND (c.partnerOwner.id=?2 OR (p.id=? 2 AND p MEMBER OF c.partners) compiles to SELECT t0_c.id FROM storecategory t0_c, partner t2_p, partner t3_c_partners, partner_categories_stor_1cl2gdd t4_c_partners_RELATION_TABLE, partner t1_c_partnerOwner WHERE (t0_c.id = ? AND (t1_c_partnerOwner.id = ? OR (t2_p.id = ? AND (t3_c_partners.id = t2_p.id AND (t0_c.id=t4_c_partners_RELATION_TABLE.StoreCategor y AND t3_c_partners.id=t4_c_partners_RELATION_TABLE.Part ner AND t0_c.partnerOwner=t1_c_partnerOwner.id); thus generating inner join which forces MEMBER OF match eliminating c.partnerOwner.id=?2 condition (see eqbql above). -- Comment By: Jeremy Boynes (jboynes) Date: 2003-01-24 15:47 Message: Logged In: YES user_id=378919 I have committed a fix for this to the HEAD branch which generates an EXISTS subquery for both MEMBER and NOT MEMBER assuming subqueries are supported. For MySQL it generates a LEFT JOIN+IS NOT NULL check. I will backport to 3.2 and 3.0 branches over the weekend. -- Comment By: Jeremy Boynes (jboynes) Date: 2003-01-23 21:46 Message: Logged In: YES user_id=378919 Please assign this to me (jboynes) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=672975group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: how's ecperf going?
Hi Bill, I am running ecperf regularly on the 3.0 and 3.2 branches. I accumulated a bunch of fixes for scalability and performance problems already, plus a few fixes for inconsistent lock usage that I will merge soon. Here are some things I noticed: * the test fails when I deploy the BMP version, some of the beans that have been created don't seem to end up in the database. * the CMP version must be tweaked to use the util.xml BMP version of the beans (search for SERIALIZABLE in the README) to work correctly * the CMP version doesn't deploy anymore on the current 3.2 branch * with the 3.2 branch I get many more spurious esceptions than with 3.0 * a HashMap in the class CachedConnectionManager seems to be the most contended lock * JAWS checks for the existence of a PK before inserting a new row in the database. This is pretty expensive. * the LogInterceptor usage of the NDC class makes it a global source of contention * TxInterceptorCMP suspends and resumes a transaction in all cases, sometimes even twice. This can be very expensive, especially with global transactions. Since I am running the tests on PowerPC Macs and the Apple VM it is hard to compare the results with other platforms. Stefan On Thursday, Jan 23, 2003, at 19:11 US/Pacific, Bill Burke wrote: Are you getting decent results? I heard from Scott that you've made some improvements. Need me to merge your changes at all? Just want to know what's up. Thanks, Bill Burke Chief Architect JBoss Group, LLC --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: FW: [JBoss-dev] [ jboss-Change Notes-672538 ] Master Configuration Service
Yes, that's the idea. It goes like this when jboss instantiates an
mbean from a *-service.xml file:
(create mbean)
state: instantiated
(set attributes)
state: configured
(call create method) ~(call destroy method)
state: created
(call start method) ~(call stop method)
state: started
where the ~() methods go backwards from the other methods.
Personally I think the create and destroy methods could be safely
removed as useless, but I lost the argument the last time we had it.
Anyway, to see why this might be useful, lets hypothesize an mbean that
takes a long time to create (just as an object) and has a socket. You
want to set the ip address and port on the socket as separate
attributes on the mbean. Well, creating a new socket whenever you
change the host or port is not very satisfactory since there's a good
chance you want to change both. Changing just one will leave the mbean
in a unusable state, pointing to the right host but wrong port. You
don't want to replace the mbean object with a new one because it takes
a long time to create. So , the service lifecycle lets you:
stop (mbean is now theoretically unusable: this should be implemented
in an interceptor, but is not right now)(this would discard the old
socket)
change both attributes (while the mbean is off)
start (this creates a new socket with all correct parameters)(mbean is
now usable again).
There are also mbean dependencies, whereby if your mbean has an
ObjectName valued attribute, and you tell jboss, your mbean can't start
until the referenced mbean has started. This is used to get most of
jboss to start in an order that will work.
The code that does this is now spread over ServiceController,
ServiceConfigurator, and ServiceContext with a little bit of
ServiceCreator thrown in.
Hope this clarifies what is going on a little bit. There are no
attributes that have no effect... its just that say a port number may
not get into the socket until you cycle the mbean, in case you want to
change the host also.
I also mentioned earlier that there's an xmbean attribute indicating
what the effect on service lifecycle should be of changing an attribute
value. The idea behind this (unimplemented) is that if you set several
attributes at once, jboss should be able to cycle the lifecycle state
for you.
david jencks
On Friday, January 24, 2003, at 05:07 PM, Matt Munz wrote:
David,
We are miscommunicating.
In all the mbeans I have written and seen in jboss, aside from
egregious bugs, if setting an attribute doesn't have an immediate
effect, it does have the desired effect if you run through the
service
lifecycle (usually stop, start, occasionally stop, destroy, create,
start). My view is that mbeans in jboss can take advantage of the
service lifecycle. If you don't want to, make all your attribute
changes have their effects immediately. All our mbeans are pretty
much
jboss specific and most heavily use the service lifecycle. They just
won't run without it. I still think it is a really convenient
extension to vanilla jmx and don't see why we should replace it.
I barely know what the service lifecycle is. I have not used it. I
am not arguing to replace it. I never said that. You said that.
How do I set an attribute correctly, step by step, for a Bean that
uses the service lifecycle?
It helps me to use a state metaphor when considering lifecycle
issues. It sounds like there are several states a lifecycle-oriented
bean can be in: destroyed, created, running. In which state is it
safe to set RW attributes on lifecycle-oriented beans?
Is the following the appropriate way to set values on a
lifecycle-oriented bean (pseudo-code)?
if(bean.isLifecycleOriented())
{
if(bean.isRunning())
{
bean.stop();
}
bean.setAttribute(newValue);
bean.start();
}
I'm here to learn :)
- Matt
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: how's ecperf going?
Thanks for the update. Can you let me know which hashmap in CachedConnectionManager is causing contention? Also, I have a plan for 4 anyway to only swap transactions when they actually change. it should be pretty easy to fix in 3/3.2 directly also. thanks david jencks On Friday, January 24, 2003, at 08:23 PM, Stefan Reich wrote: Hi Bill, I am running ecperf regularly on the 3.0 and 3.2 branches. I accumulated a bunch of fixes for scalability and performance problems already, plus a few fixes for inconsistent lock usage that I will merge soon. Here are some things I noticed: * the test fails when I deploy the BMP version, some of the beans that have been created don't seem to end up in the database. * the CMP version must be tweaked to use the util.xml BMP version of the beans (search for SERIALIZABLE in the README) to work correctly * the CMP version doesn't deploy anymore on the current 3.2 branch * with the 3.2 branch I get many more spurious esceptions than with 3.0 * a HashMap in the class CachedConnectionManager seems to be the most contended lock * JAWS checks for the existence of a PK before inserting a new row in the database. This is pretty expensive. * the LogInterceptor usage of the NDC class makes it a global source of contention * TxInterceptorCMP suspends and resumes a transaction in all cases, sometimes even twice. This can be very expensive, especially with global transactions. Since I am running the tests on PowerPC Macs and the Apple VM it is hard to compare the results with other platforms. Stefan On Thursday, Jan 23, 2003, at 19:11 US/Pacific, Bill Burke wrote: Are you getting decent results? I heard from Scott that you've made some improvements. Need me to merge your changes at all? Just want to know what's up. Thanks, Bill Burke Chief Architect JBoss Group, LLC --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-674432 ] lock starvation with Ecperf
Bugs item #674432, was opened at 2003-01-24 18:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=674432group_id=22866 Category: JBossMX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Stefan Reich (sreich) Assigned to: Nobody/Anonymous (nobody) Summary: lock starvation with Ecperf Initial Comment: I ran Ecperf on JDK 1.4.1 on MacOSX with CMP deployment on Jboss 3.0.6 latest from today. The test stopped after a while. I was only able to reproduce it once so far, with the -Xint flag. I got one thread with the following trace: RMI TCP Connection(127)-17.205.41.241 daemon prio=5 tid=0x04b88490 nid=0x4b23c70 in Object.wait() [f98ac000..f98b0b70] at java.lang.Object.wait(Native Method) - waiting on 0x5d3996f0 (a org.jboss.mx.loading.ClassLoadingTask) at java.lang.Object.wait(Object.java:426) at org.jboss.mx.loading.LoadMgr.nextTask(LoadMgr.java:229) - locked 0x5d3996f0 (a org.jboss.mx.loading.ClassLoadingTask) at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:165) - locked 0x5aa54640 (a org.jboss.mx.loading.UnifiedClassLoader3) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) - locked 0x5aa54640 (a org.jboss.mx.loading.UnifiedClassLoader3) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:140) at com.sun.ecperf.ruleengine.CachedClass.init(CachedClass.java:44) at com.sun.ecperf.ruleengine.ClassCache.forName(ClassCache.java:61) at com.sun.ecperf.ruleengine.RuleProcessor.firstIdentifier(RuleProcessor.java:5487) at com.sun.ecperf.ruleengine.RuleProcessor.evalName(RuleProcessor.java:5682) Another thread waiting on the first thread had the lock to class loader instance 0x5aa54640: RMI TCP Connection(203)-17.205.41.241 daemon prio=5 tid=0x04bc4ad0 nid=0x4b2fdc0 waiting for monitor entry [fbefb000..fbefcb70] at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:120) - waiting to lock 0x5aa54640 (a org.jboss.mx.loading.UnifiedClassLoader3) at java.lang.ClassLoader.loadClass(ClassLoader.java:292) - locked 0x5ac4ce88 (a org.jboss.web.WebClassLoader) at java.lang.ClassLoader.loadClass(ClassLoader.java:292) - locked 0x5ac4a248 (a java.net.URLClassLoader) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at org.jboss.invocation.MarshalledValueInputStream.resolveClass(MarshalledValueInputStream.java:37) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513) All other threads were blocked waiting on the lock for the classloader 0x5ac4a248: RMI TCP Connection(128)-17.205.41.241 daemon prio=5 tid=0x04b89010 nid=0x4b23ed0 waiting for monitor entry [f993..f9931b70] at java.lang.ClassLoader.loadClass(ClassLoader.java:288) - waiting to lock 0x5aa5c288 (a java.net.URLClassLoader) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at org.jboss.invocation.MarshalledValueInputStream.resolveClass(MarshalledValueInputStream.java:37) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) at org.jboss.invocation.MarshalledValue.get(MarshalledValue.java:78) I have a 50MB log about the class loading details. The only noteworthy event in the last entries in the log file was this exception: [856915,LoadMgr,RMI TCP Connection(127)-17.205.41.241] nextTask(WAIT_ON_EVENT), interrupted java.lang.InterruptedException at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:426) at org.jboss.mx.loading.LoadMgr.nextTask(LoadMgr.java:229) at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:165) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:140) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=674432group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED]
[JBoss-dev] [ jboss-Bugs-672975 ] MEMBER OF generates inner joins
Bugs item #672975, was opened at 2003-01-23 01:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=672975group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Pending Resolution: Fixed Priority: 5 Submitted By: Alexei Yudichev (sflexus) Assigned to: Jeremy Boynes (jboynes) Summary: MEMBER OF generates inner joins Initial Comment: == This is a bug. Please file a bug report at sourceforge. MEMBER OF should be generating a sub select or a left join. This is simmilar to the IS NULL bug we recently fixed. -dain == SELECT OBJECT(c) FROM StoreCategory c, Partner p WHERE c.id=?1 AND (c.partnerOwner.id=?2 OR (p.id=? 2 AND p MEMBER OF c.partners) compiles to SELECT t0_c.id FROM storecategory t0_c, partner t2_p, partner t3_c_partners, partner_categories_stor_1cl2gdd t4_c_partners_RELATION_TABLE, partner t1_c_partnerOwner WHERE (t0_c.id = ? AND (t1_c_partnerOwner.id = ? OR (t2_p.id = ? AND (t3_c_partners.id = t2_p.id AND (t0_c.id=t4_c_partners_RELATION_TABLE.StoreCategor y AND t3_c_partners.id=t4_c_partners_RELATION_TABLE.Part ner AND t0_c.partnerOwner=t1_c_partnerOwner.id); thus generating inner join which forces MEMBER OF match eliminating c.partnerOwner.id=?2 condition (see eqbql above). -- Comment By: Jeremy Boynes (jboynes) Date: 2003-01-24 21:49 Message: Logged In: YES user_id=378919 This has now been committed to Branch_3_0 and Branch_3_2 as well. -- Comment By: Jeremy Boynes (jboynes) Date: 2003-01-24 15:47 Message: Logged In: YES user_id=378919 I have committed a fix for this to the HEAD branch which generates an EXISTS subquery for both MEMBER and NOT MEMBER assuming subqueries are supported. For MySQL it generates a LEFT JOIN+IS NOT NULL check. I will backport to 3.2 and 3.0 branches over the weekend. -- Comment By: Jeremy Boynes (jboynes) Date: 2003-01-23 21:46 Message: Logged In: YES user_id=378919 Please assign this to me (jboynes) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=672975group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
