Re: [JBoss-dev] Re: Hibernate deployer?
Understood. Bill Burke wrote: Yes, please focus on a hibernate-centric deployer and seemless integration of Hibernate with JBoss deployment, management(JMX), TM, and classloading. This is much more important that integration with the EJB deployer. Bill Gavin King wrote: Alex is currently the one working on this idea - it is certainly the plan. Still, I think we need a separate Hibernate-centric deployer as well. Gavin Andrew Oliver wrote: A suggestion: Integrate with the EJB deployer. It would be good to mix EJBs and hibernated stuff. Meaning I could feasibly have jbosscmp-jdbc.xml, jaws.xml and hibernate.xml in the same ejb-jar.jar. This also gives us a chance to ditch the present CMP engine and use a wrapper around hibernate to provide EJB persistence. -Andy From: Gavin King <[EMAIL PROTECTED]> Date: Wed, 24 Dec 2003 17:43:23 +0700 To: Andrew Oliver <[EMAIL PROTECTED]> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Subject: Re: Hibernate deployer? I won't get onto this until the new year. After that, i will try to make it happen as quickly as possible. Andrew Oliver wrote: I'm working on getting up to speed with Hibernate. I started following these (http://hibernate.org/66.html) instructions but I'd rather have only 1 instance of Hibernate for all of my hibernated stuff. How far along is the deployer? I'm running the HEAD and the SAR seems happy. I'm willing to help the deployer along if you point me to it. Thanks, Andy cc: Gavin as I don't know if he's watching -- Gavin King JBoss Group +61 410534454 http://hibernate.org -- Gavin King JBoss Group +61 410534454 http://hibernate.org --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-860175 ] NotSerializableException when using "twiddle" for a XMBean
Bugs item #860175, was opened at 2003-12-15 12:05 Message generated for change (Comment added) made by srivatsanp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=860175&group_id=22866 Category: JBossMX Group: v3.2 >Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Srivatsan (srivatsanp) Assigned to: Scott M Stark (starksm) Summary: NotSerializableException when using "twiddle" for a XMBean Initial Comment: When a XMBean has an attribute of type Element, invoking that MBean through twiddle results in NotSerializableException. Please find attached the zip containing the source, descriptors and the sar used for testing. sh twiddle.sh invoke "jboss.test:service=TestXMBean" create twiddle.sh: RuntimeMBeanException: null Cause: org.jboss.util.NestedRuntimeException: error unmarshalling return; nested exception is: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.crimson.tree.ElementNode; - nested throwable: (java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.crimson.tree.ElementNode) I am using JBoss 3.2.1 -- >Comment By: Srivatsan (srivatsanp) Date: 2004-01-06 10:22 Message: Logged In: YES user_id=687037 I am not accessing the non serializable attribute from twiddle. I am just invoking some other operation on the MBean. It fails even in that case. Thanks, Srivatsan -- Comment By: Scott M Stark (starksm) Date: 2004-01-05 22:40 Message: Logged In: YES user_id=175228 Accessing JMX over a remote channel as twiddle requires, will only work with types that are serializable. Until the JMX1.2 with remoting you are restricted to accessing serializable attributes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=860175&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 代码表快速录入web控件
WebCode控件 随着web方式的应用系统逐渐进入业务支撑系统的领域，各种c/s结构的优点也相应暴露出来，对b/s方式的业务系统也必将提出一些c/s结构的系统所具备的特点。在业务信息输入时，能够支持代码信息输入、同时允许拼音码自动过滤就是其中一个基本特点。 WebCode(网页代码输入控件)就是要满足这种目前只有在c/s模式下才能看到的，高效率的web plugin，它提供applet和ocx两种版本，满足sun体系和microsoft体系的web 应用系统，让软件公司可以根据需要开发出更好的web 应用系统。 本控件需要替换html的基本控件，让其支持手工输入代码、拼音等，然后该控件将自动将符合条件的列表信息显示出来，使得输入信息更加方便快捷，满足生产（业务）系统信息频繁录入的要求。使用该控件的软件开发商只需要按照一定的书写规则在其需要的web程序内嵌入该控件即可使用它。 在线介绍及演示地址： http://webcomponent.yeah.net
[JBoss-dev] ServiceController MBean unload ordering
Obscure question: Is there a way to instruct the ServiceController to unload an MBean (as near) at the end of the lifecycle of all the other mbeans? Use case: In remoting, ideally you want to have the remoting framework load at the last possible minute so that notifications from all the other mbeans will be attempted to be delivered before the server is shutdown. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Remoting and NAT traversal, advanced network
In the remoting framework, there are three main components: a transport,
a detector and a network registry. (among others .. but these are the
biggest)
The transport encapsulates the client and server components necessary
for communication for a given protocol between two endpoints.
The detector is a specific protocol/mechanism for handling discovery and
failure of zero or more endpoints based on a domain (or a cluster,
partition, whatever you'd like to call it - a logical grouping of
machines with the same name).
For transports, we have sockets (TCP), RMI, SOAP.
For detectors, we have multicast, JNDI.
The next major component is the network registry which receives
detection notifications (or you can call it directly to enlist servers)
which keeps a network map of all machines (and their identity and valid
transports and how to communicate with them) within the same logical domain.
In JMX remoting, a simple proxy is created for the JMX subsystem (you
can have other subsystems such as AOP, JMS, etc.) which uses a transport
(unknown to the proxy) to communicate with the remote MBeanServer.
This allows you to mix and match transports, detection/failure
mechanisms and subsystems that use the framework.
In AOP Remoting, you can simply instrument an object, given a remote
locator (which could be obtained via detection) and then make remote
method calls against it w/o RMI stubs, etc.
We make heavy use of something called an MBeanTracker which is in JMX
Remoting.
You can give the mbean tracker a set of interfaces, query expression,
and any combination/ lack thereof and he will automatically give you
back a callback for things such as register, unregister, notification
and a MBeanLocator which can be turned into a proxy to that object.
For example:
MBeanTracker tracker=new MBeanTracker(getServer(), new
Class[]{Server.class}, null, false, null, true, new
MBeanTrackerActionAdapter()
{
public void mbeanRegistered (MBeanLocator locator)
{
System.out.println("I found a new JBoss server at: "+locator+" on
the network");
// cast to a server proxy that implements the Server interface
Server server = (Server)locator.narrow(Server.class);
// look ma... no hands, I just shutdown your jboss server remotely
server.shutdown();
}
public void mbeanUnregistered (MBeanLocator locator)
{
System.out.println("I lost a JBoss server at: "+locator+" on the
network");
}
public void mbeanNotification (MBeanLocator locator, Notification
notification, Object handback)
{
System.out.println("JBoss server at: "+locator+" sent a
notification: "+notification);
}
});
It's as simple as that. You can deal with network transparency (in a
novel way), failure, detection, etc. in short-order - with very little
code - but very very powerful.
And, no Marc, this isn't relegated to just JMX as Bill demonstrates with
AOP Remoting. This should be used for JMS, EJB and all the other
subsystem layers. ;)
Jeff
Scott M Stark wrote:
We use system properties that allow client environments to override
the URL used to connect to in the RMI/HTTP transport for this
issue.
What is the detection notification you are talking about here? I have
not looked at the remoting code much so describe the network traffic.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Haynie
Sent: Monday, January 05, 2004 2:04 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Remoting and NAT traversal, advanced network
We have a customer that needs to use JBoss Remoting / JMX Remoting in a
fairly complex, although not unusual, network configuration.
Right now, we don't well support dynamic / NAT traversals for remoting
either in detection or transport. We basically send the local machines
address (which bind address is configurable) as part of the detection
notification to the remote machine. This works fine on a local subnet.
In the case of a remote subnet, you can use the JNDI detection which
will bind the entry into a remote (or local) JNDI context which can then
be browsed by any network that can reach the JNDI server.
In cases where NAT is being used (or potentially even DHCP, although
slightly different), we need to be able to send the detection annotated
with additional network interfaces, such as the public IP or hostname.
Ideally, this could be a simple configuration that we would read /
lookup (maybe as simple as a system property) and the Identity could be
modified to include additional addresses (similar to InetAddress when
you have multiple NICs locally). Then, the remote machine transport
could then try the primary address and then secondary addresses if the
primarily failed.
In addition, I wrote a SSHConnector that uses SSH tunneling (totally
dynamic, not setup except giving it the credentials) on both sides to do
SSH transport - I
RE: [JBoss-dev] Remoting and NAT traversal, advanced network
We use system properties that allow client environments to override the URL used to connect to in the RMI/HTTP transport for this issue. What is the detection notification you are talking about here? I have not looked at the remoting code much so describe the network traffic. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Haynie Sent: Monday, January 05, 2004 2:04 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Remoting and NAT traversal, advanced network We have a customer that needs to use JBoss Remoting / JMX Remoting in a fairly complex, although not unusual, network configuration. Right now, we don't well support dynamic / NAT traversals for remoting either in detection or transport. We basically send the local machines address (which bind address is configurable) as part of the detection notification to the remote machine. This works fine on a local subnet. In the case of a remote subnet, you can use the JNDI detection which will bind the entry into a remote (or local) JNDI context which can then be browsed by any network that can reach the JNDI server. In cases where NAT is being used (or potentially even DHCP, although slightly different), we need to be able to send the detection annotated with additional network interfaces, such as the public IP or hostname. Ideally, this could be a simple configuration that we would read / lookup (maybe as simple as a system property) and the Identity could be modified to include additional addresses (similar to InetAddress when you have multiple NICs locally). Then, the remote machine transport could then try the primary address and then secondary addresses if the primarily failed. In addition, I wrote a SSHConnector that uses SSH tunneling (totally dynamic, not setup except giving it the credentials) on both sides to do SSH transport - I need to get this into remoting soon. This is an additional option, but not as flexible and slower. Does anyone have any good ideas, suggestions, criticisms on this topic? --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] NPE when shutting down a host
It says you are trying to use a classloader that has been removed from the repository. Is it just a doing a Class.forName()? I wouldn't have thought the classloader for StandardHost would have been removed at that point. Regards, Adrian On Mon, 2004-01-05 at 22:00, Remy Maucherat wrote: > Going back to the TC 5 integration, I run into a problem while > undeploying the SAR: > > 22:50:47,367 ERROR [StandardHost] Error creating deployer > java.lang.NullPointerException > at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:119) > at > org.jboss.mx.loading.UnifiedClassLoader3.loadClassImpl(UnifiedClassLoader3.java:185) > at > org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:139) > at java.lang.ClassLoader.loadClass(ClassLoader.java:235) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > org.apache.catalina.core.StandardHost.getDeployer(StandardHost.java:1019) > at > org.apache.catalina.core.StandardHost.findDeployedApps(StandardHost.java:916) > at > org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1042) > at > org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1024) > at > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:395) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) > at > org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1165) > at > org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1177) > at > org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:523) > at > org.apache.catalina.core.StandardService.stop(StandardService.java:575) > at > org.apache.catalina.core.StandardServer.stop(StandardServer.java:2379) > at org.apache.catalina.startup.Catalina.stop(Catalina.java:647) > 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.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503) > at > org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:72) > at > org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:544) > at org.jboss.web.tomcat.tc5.Tomcat5.stopService(Tomcat5.java:173) > at > org.jboss.system.ServiceMBeanSupport.stop(ServiceMBeanSupport.java:240) > > > I think this is caused by the JMX 1.2 checkin in the 3.2 branch. > Any idea of a workaround ? -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] NPE when shutting down a host
Going back to the TC 5 integration, I run into a problem while undeploying the SAR: 22:50:47,367 ERROR [StandardHost] Error creating deployer java.lang.NullPointerException at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:119) at org.jboss.mx.loading.UnifiedClassLoader3.loadClassImpl(UnifiedClassLoader3.java:185) at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:139) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.catalina.core.StandardHost.getDeployer(StandardHost.java:1019) at org.apache.catalina.core.StandardHost.findDeployedApps(StandardHost.java:916) at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1042) at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1024) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:395) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1165) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1177) at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:523) at org.apache.catalina.core.StandardService.stop(StandardService.java:575) at org.apache.catalina.core.StandardServer.stop(StandardServer.java:2379) at org.apache.catalina.startup.Catalina.stop(Catalina.java:647) 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.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503) at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:72) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:544) at org.jboss.web.tomcat.tc5.Tomcat5.stopService(Tomcat5.java:173) at org.jboss.system.ServiceMBeanSupport.stop(ServiceMBeanSupport.java:240) I think this is caused by the JMX 1.2 checkin in the 3.2 branch. Any idea of a workaround ? -- x Rémy Maucherat Senior Developer & Consultant JBoss Group (Europe) SàRL x --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build not working with Ant 1.6.0
Ah, you're right - I typed ant instead. I always use build with jboss
and ant for everything else and I forgot this time.
However, ant 1.6.0 does work fine so the check should be updated either way.
Jeff
Adrian Brock wrote:
It is recommended that you build with the ant from tools
using build.bat
You should change the failure check rather than the version:
Unsupported Ant version:
${ant.version}
Please install a version which is compatible with Ant
${buildmagic.ant.baseversion}.
Regards,
Adrian
On Mon, 2004-01-05 at 22:59, Jeff Haynie wrote:
C:\cvs\jboss-3.2\build>ant
Buildfile: build.xml
_buildmagic:init:
BUILD FAILED
C:\cvs\jboss-3.2\tools\etc\buildmagic\buildmagic.ent:25:
Unsupported Ant version:
Apache Ant version 1.6.0 compiled on December 18 2003
Please install a version which is compatible with Ant 1.5.
Total time: 1 second
C:\cvs\jboss-3.2\build>notepad
C:\cvs\jboss-3.2\tools\etc\buildmagic\buildmagic.ent
I updated buildmagic.ant
and re-built fine. Is there any reason to not make this change and
check it in to CVS?
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Build not working with Ant 1.6.0
It is recommended that you build with the ant from tools
using build.bat
You should change the failure check rather than the version:
Unsupported Ant version:
${ant.version}
Please install a version which is compatible with Ant
${buildmagic.ant.baseversion}.
Regards,
Adrian
On Mon, 2004-01-05 at 22:59, Jeff Haynie wrote:
> C:\cvs\jboss-3.2\build>ant
> Buildfile: build.xml
>
> _buildmagic:init:
>
> BUILD FAILED
> C:\cvs\jboss-3.2\tools\etc\buildmagic\buildmagic.ent:25:
>
> Unsupported Ant version:
>
> Apache Ant version 1.6.0 compiled on December 18 2003
>
> Please install a version which is compatible with Ant 1.5.
>
> Total time: 1 second
> C:\cvs\jboss-3.2\build>notepad
> C:\cvs\jboss-3.2\tools\etc\buildmagic\buildmagic.ent
>
>
> I updated buildmagic.ant
>
>
>
> and re-built fine. Is there any reason to not make this change and
> check it in to CVS?
>
>
>
> ---
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> ___
> JBoss-Development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-870541 ] Nukes not evaluting ${config:minAge} correctly
Bugs item #870541, was opened at 2004-01-04 21:46
Message generated for change (Comment added) made by dan_higgins1
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870541&group_id=22866
Category: Nukes
Group: CVS HEAD
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Higgins (dan_higgins1)
Assigned to: Julien Viet (cooperfbi)
Summary: Nukes not evaluting ${config:minAge} correctly
Initial Comment:
The file ../modules/user/module.html has the following
code which is not working properly:
...
${user.WelcomeTo} ${config:siteName} ${user.Registration}
...
${user.MustBe_1} ${config:minAge} ${user.MustBe_2}
...
The checkage page shows " ..18 or over, or have
parental permission to register here."
The number 18 is currently hardcoded in
Resource_en_US.properties file.
The minAge attribute has a value set in the core mbean
but is not parsed correctly.
--
>Comment By: Dan Higgins (dan_higgins1)
Date: 2004-01-05 21:56
Message:
Logged In: YES
user_id=464007
The bug is in the create method of the CoreModule.java file.
The current code is only returning objects that are of type
String. minAge is a number and therefore null is being returned.
Below is a listing of the previous code and a potential fix.
//return (value instanceof String) ? (String) value : null;
return (value != null) ? String.valueOf(value) : null;
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870541&group_id=22866
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Build not working with Ant 1.6.0
C:\cvs\jboss-3.2\build>ant Buildfile: build.xml _buildmagic:init: BUILD FAILED C:\cvs\jboss-3.2\tools\etc\buildmagic\buildmagic.ent:25: Unsupported Ant version: Apache Ant version 1.6.0 compiled on December 18 2003 Please install a version which is compatible with Ant 1.5. Total time: 1 second C:\cvs\jboss-3.2\build>notepad C:\cvs\jboss-3.2\tools\etc\buildmagic\buildmagic.ent I updated buildmagic.ant and re-built fine. Is there any reason to not make this change and check it in to CVS? --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Remoting and NAT traversal, advanced network
We have a customer that needs to use JBoss Remoting / JMX Remoting in a fairly complex, although not unusual, network configuration. Right now, we don't well support dynamic / NAT traversals for remoting either in detection or transport. We basically send the local machines address (which bind address is configurable) as part of the detection notification to the remote machine. This works fine on a local subnet. In the case of a remote subnet, you can use the JNDI detection which will bind the entry into a remote (or local) JNDI context which can then be browsed by any network that can reach the JNDI server. In cases where NAT is being used (or potentially even DHCP, although slightly different), we need to be able to send the detection annotated with additional network interfaces, such as the public IP or hostname. Ideally, this could be a simple configuration that we would read / lookup (maybe as simple as a system property) and the Identity could be modified to include additional addresses (similar to InetAddress when you have multiple NICs locally). Then, the remote machine transport could then try the primary address and then secondary addresses if the primarily failed. In addition, I wrote a SSHConnector that uses SSH tunneling (totally dynamic, not setup except giving it the credentials) on both sides to do SSH transport - I need to get this into remoting soon. This is an additional option, but not as flexible and slower. Does anyone have any good ideas, suggestions, criticisms on this topic? --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-871181 ] Run.bat includes current directory in classpath
Bugs item #871181, was opened at 2004-01-05 19:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=871181&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Keenan Ross (keenanross) Assigned to: Nobody/Anonymous (nobody) Summary: Run.bat includes current directory in classpath Initial Comment: On MS Windows, if you have NOT set the JBOSS_CLASSPATH environment variable, and then execute the JBoss 3.2.2 run.bat from a DOS box, the server will echo: . JBoss Bootstrap Environment . JBOSS_HOME: C:\jboss\jboss-3.2.2_jetty-4.2.11\bin\.. . JAVA: c:\j2sdk1.4.2_02\bin\java . JAVA_OPTS: -Dprogram.name=run.bat . CLASSPATH: ;c:\j2sdk1.4.2_02\lib\tools.jar;C:\jboss\jboss-3.2.2_jetty-4.2.11\bin\run.jar . NOTE the leading semicolon in the value of the claspath, which the Java VM interprets as the current directory. If that directory contains extraneous .class or .property files, hard to track down problems can be introduced. The UNIX version of the start script, run.sh, does not suffer from this problem. Its logic, an explicit check for a non-existant JBOSS_CLASSPATH, could be used in run.bat to fix this bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=871181&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] What is this codeblock in BasicMBeanRegistry
Ok, I'm on it. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Monday, January 05, 2004 10:44 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] What is this codeblock in BasicMBeanRegistry On Mon, 2004-01-05 at 18:21, Scott M Stark wrote: > So to move the TCL handling to the invoker, I need the MBeanEntry in > the AbstractMBeanInvoker. This really could replace the current > resource reference since this is encapsulated by the MBeanEntry. > This would have to be looked up during the preRegister call into the > invoker. Anyone see a problem with this change? > This is a change I've been meaning to do for a while. But it never reached the top of my todo list. I don't see any problem with this approach. It would remove this work from the MBeanServer. The only other point of entry into an MBean is for the notifications. But the setting of the TCL isn't supported under the current processing either. The other outstanding issue is whether createMBean or registerMBean without a classloader should be registered with the current TCL. Currently it uses either no classloader or the MBeanServer's classloader. This is for use cases where code running under a Heirarchical Loader Repository registers an MBean using the standard JMX interface. Currently it will not be registered with a classloader from the Heirarchical Loader Repository (which is confusing at best). Regards, Adrian --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] What is this codeblock in BasicMBeanRegistry
On Mon, 2004-01-05 at 18:21, Scott M Stark wrote:
> So to move the TCL handling to the invoker, I need the MBeanEntry
> in the AbstractMBeanInvoker. This really could replace the current
> resource reference since this is encapsulated by the MBeanEntry.
> This would have to be looked up during the preRegister call into
> the invoker. Anyone see a problem with this change?
>
This is a change I've been meaning to do for a while.
But it never reached the top of my todo list.
I don't see any problem with this approach. It would remove
this work from the MBeanServer.
The only other point of entry into an MBean is for
the notifications. But the setting of the TCL isn't supported under the
current processing either.
The other outstanding issue is whether createMBean or registerMBean
without a classloader should be registered with the current TCL.
Currently it uses either no classloader or the MBeanServer's
classloader.
This is for use cases where code running under a
Heirarchical Loader Repository registers an MBean
using the standard JMX interface. Currently it will
not be registered with a classloader from the
Heirarchical Loader Repository (which is confusing at best).
Regards,
Adrian
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Adrian Brock
> Sent: Monday, January 05, 2004 9:39 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] What is this codeblock in BasicMBeanRegistry
>
> If I remember correctly, this was a fix for some changes in the service
> controller made in 4.0.0DR1
>
> AFAIK the code that required this fix is no longer present since the
> rollback by Bill.
>
> You are correct that the invocation of the MBean's preRegister should be
> done with the classloader.
> You can argue that the TCL should be a responsibilty of the invoker via
> an interceptor rather than the MBeanServer.
>
> Regards,
> Adrian
>
> On Mon, 2004-01-05 at 15:44, Scott M Stark wrote:
> > org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean
> > is the following codeblock:
> >
> > // This is a fix for the SAR TCL problem in 4.0
> > // Allow the classloader in the value map to be an ObjectName
> > if (valueMap != null)
> > {
> > Object obj = valueMap.get(CLASSLOADER);
> > if (obj != null && obj instanceof ObjectName)
> > {
> > MBeanEntry clEntry = null;
> > try
> > {
> > clEntry = get((ObjectName) obj);
> > }
> > catch (InstanceNotFoundException e)
> > {
> >throw new RuntimeOperationsException(
> > new IllegalArgumentException(e.toString()));
> > }
> > valueMap.put(CLASSLOADER, clEntry.getResourceInstance());
> > }
> > }
> >
> > What is this for? The following dispatch to the invokePreRegister is
> > not using the correct thread context class loader. It needs to be
> > using the class loader of the mbean being registered so that any
> > scoped classes that are loaded as part of the registration are
> > available. I'm correcting this, but I need to know what the source of
> > this duality of type is.
> >
> >
> > Scott Stark
> > Chief Technology Officer
> > JBoss Group, LLC
> >
> >
> >
> >
> > ---
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills. Sign up for
> > IBM's Free Linux Tutorials. Learn everything from the bash shell to
> sys admin.
> > Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
> > ___
> > JBoss-Development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> --
>
> Adrian Brock
> Director of Support
> Back Office
> JBoss Group, LLC
>
>
>
>
> ---
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for
> IBM's Free Linux Tutorials. Learn everything from the bash shell to sys
> admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> ___
> JBoss-Development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
>
> ---
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
> __
RE: [JBoss-dev] What is this codeblock in BasicMBeanRegistry
So to move the TCL handling to the invoker, I need the MBeanEntry
in the AbstractMBeanInvoker. This really could replace the current
resource reference since this is encapsulated by the MBeanEntry.
This would have to be looked up during the preRegister call into
the invoker. Anyone see a problem with this change?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Adrian Brock
Sent: Monday, January 05, 2004 9:39 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] What is this codeblock in BasicMBeanRegistry
If I remember correctly, this was a fix for some changes in the service
controller made in 4.0.0DR1
AFAIK the code that required this fix is no longer present since the
rollback by Bill.
You are correct that the invocation of the MBean's preRegister should be
done with the classloader.
You can argue that the TCL should be a responsibilty of the invoker via
an interceptor rather than the MBeanServer.
Regards,
Adrian
On Mon, 2004-01-05 at 15:44, Scott M Stark wrote:
> org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean
> is the following codeblock:
>
> // This is a fix for the SAR TCL problem in 4.0
> // Allow the classloader in the value map to be an ObjectName
> if (valueMap != null)
> {
> Object obj = valueMap.get(CLASSLOADER);
> if (obj != null && obj instanceof ObjectName)
> {
> MBeanEntry clEntry = null;
> try
> {
> clEntry = get((ObjectName) obj);
> }
> catch (InstanceNotFoundException e)
> {
>throw new RuntimeOperationsException(
> new IllegalArgumentException(e.toString()));
> }
> valueMap.put(CLASSLOADER, clEntry.getResourceInstance());
> }
> }
>
> What is this for? The following dispatch to the invokePreRegister is
> not using the correct thread context class loader. It needs to be
> using the class loader of the mbean being registered so that any
> scoped classes that are loaded as part of the registration are
> available. I'm correcting this, but I need to know what the source of
> this duality of type is.
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
>
>
>
> ---
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for
> IBM's Free Linux Tutorials. Learn everything from the bash shell to
sys admin.
> Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
> ___
> JBoss-Development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for
IBM's Free Linux Tutorials. Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] What is this codeblock in BasicMBeanRegistry
Ok, let me see if that looks to be a better place to handle the TCL. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Monday, January 05, 2004 9:39 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] What is this codeblock in BasicMBeanRegistry If I remember correctly, this was a fix for some changes in the service controller made in 4.0.0DR1 AFAIK the code that required this fix is no longer present since the rollback by Bill. You are correct that the invocation of the MBean's preRegister should be done with the classloader. You can argue that the TCL should be a responsibilty of the invoker via an interceptor rather than the MBeanServer. Regards, Adrian --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] What is this codeblock in BasicMBeanRegistry
If I remember correctly, this was a fix for some
changes in the service controller made in 4.0.0DR1
AFAIK the code that required this fix is no longer present
since the rollback by Bill.
You are correct that the invocation of the MBean's
preRegister should be done with the classloader.
You can argue that the TCL should be a responsibilty of
the invoker via an interceptor rather than the MBeanServer.
Regards,
Adrian
On Mon, 2004-01-05 at 15:44, Scott M Stark wrote:
> org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean
> is the following codeblock:
>
> // This is a fix for the SAR TCL problem in 4.0
> // Allow the classloader in the value map to be an ObjectName
> if (valueMap != null)
> {
> Object obj = valueMap.get(CLASSLOADER);
> if (obj != null && obj instanceof ObjectName)
> {
> MBeanEntry clEntry = null;
> try
> {
> clEntry = get((ObjectName) obj);
> }
> catch (InstanceNotFoundException e)
> {
>throw new RuntimeOperationsException(
> new IllegalArgumentException(e.toString()));
> }
> valueMap.put(CLASSLOADER, clEntry.getResourceInstance());
> }
> }
>
> What is this for? The following dispatch to the invokePreRegister is
> not using the correct thread context class loader. It needs to be using
> the class loader of the mbean being registered so that any scoped
> classes
> that are loaded as part of the registration are available. I'm
> correcting
> this, but I need to know what the source of this duality of type is.
>
>
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
>
>
>
>
> ---
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
> ___
> JBoss-Development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-860175 ] NotSerializableException when using "twiddle" for a XMBean
Bugs item #860175, was opened at 2003-12-14 22:35 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=860175&group_id=22866 Category: JBossMX Group: v3.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Srivatsan (srivatsanp) >Assigned to: Scott M Stark (starksm) Summary: NotSerializableException when using "twiddle" for a XMBean Initial Comment: When a XMBean has an attribute of type Element, invoking that MBean through twiddle results in NotSerializableException. Please find attached the zip containing the source, descriptors and the sar used for testing. sh twiddle.sh invoke "jboss.test:service=TestXMBean" create twiddle.sh: RuntimeMBeanException: null Cause: org.jboss.util.NestedRuntimeException: error unmarshalling return; nested exception is: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.crimson.tree.ElementNode; - nested throwable: (java.rmi.UnmarshalException: error unmarshalling return; nested exception is: java.io.WriteAbortedException: writing aborted; java.io.NotSerializableException: org.apache.crimson.tree.ElementNode) I am using JBoss 3.2.1 -- >Comment By: Scott M Stark (starksm) Date: 2004-01-05 09:10 Message: Logged In: YES user_id=175228 Accessing JMX over a remote channel as twiddle requires, will only work with types that are serializable. Until the JMX1.2 with remoting you are restricted to accessing serializable attributes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=860175&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-870942 ] Classloader problem with ear file
Bugs item #870942, was opened at 2004-01-05 08:54 Message generated for change (Comment added) made by swolfangel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Wolfangel (swolfangel) Assigned to: Scott M Stark (starksm) Summary: Classloader problem with ear file Initial Comment: Hello, I have an ear file that contains 2 stateless session beans and all the 3rd party jars required by the beans. The 3rd party jars contain older jdom classes than the jdom jar included in the jboss lib dir. I have a unique classloader setup (in the jboss-app.xml file) but I am having problems with jdom. It is finding the jboss jdom classes instead of the ones included in the ear. when I change the jboss-app.xml file to contain the following lines: com.metamatrix:loader=MM.ear java2ParentDelegation=false I get a NoClassDefFoundError. java.lang.NoClassDefFoundError: java/sql/SQLException This class is in the rt.jar file in the jdk! I was under the impression that setting java2ParentDelegation to false meant that if the class was not found using the local classloader then the parent classloader would be called. In a nutshell, when I have java2ParentDelegation set to true, I get the jdom problem, when I have java2ParentDelegation set to false I am unable to see classes that are in the rt.jar file. Here is the output when starting the server. [Server] Starting JBoss (MX MicroKernel)... [Server] Release ID: JBoss [WonderLand] 3.2.3 (build: CVSTag=JBoss_3_2_3 date=200311301445) [Server] Home Dir: D:\mm40\jb32\server\jboss [Server] Home URL: file:/D:/mm40/jb32/server/jboss/ [Server] Library URL: file:/D:/mm40/jb32/server/jboss/lib/ [Server] Patch URL: null [Server] Server Name: metamatrix [Server] Server Home Dir: D:\mm40\jb32 \server\jboss\server\metamatrix [Server] Server Home URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/ [Server] Server Data Dir: D:\mm40\jb32 \server\jboss\server\metamatrix\data [Server] Server Temp Dir: D:\mm40\jb32 \server\jboss\server\metamatrix\tmp [Server] Server Config URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/conf/ [Server] Server Library URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/lib/ [Server] Root Deployment Filename: jboss-service.xml [Server] Starting General Purpose Architecture (GPA)... [ServerInfo] Java version: 1.4.2,Sun Microsystems Inc. [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.4.2-b28,Sun Microsystems Inc. [ServerInfo] OS-System: Windows XP 5.1,x86 -- >Comment By: Steve Wolfangel (swolfangel) Date: 2004-01-05 11:09 Message: Logged In: YES user_id=541224 Attached log.zip file containing ucl.log and server.log -- Comment By: Scott M Stark (starksm) Date: 2004-01-05 10:40 Message: Logged In: YES user_id=175228 Next step, add the following to the conf/log4j.xml and send me the resulting server.log and ucl.log zipped up as the ucl.log can be large: [EMAIL PROTECTED] -- Comment By: Scott M Stark (starksm) Date: 2004-01-05 10:33 Message: Logged In: YES user_id=175228 Yes, and there is a testcase in 3.2 for replacing the xml parser with a different version of xerces for example, using this approach. The problem with overriding the various xml related classes is that these are used all over and not all contexts are correctly limiting the scope of the classes they use. Presumably this is the case for the jdom usage. -- Comment By: Steve Wolfangel (swolfangel) Date: 2004-01-05 09:41 Message: Logged In: YES user_id=541224 Replacing the jdom.jar file got me past this problem. I am still interested in finding the correct solution since there is a chance I could have similar problems in the future. Am I correct by assuming that by setting up my own classloader and setting java2ParentDelegation to false in the jboss-app file is the correct approach? -- Comment By: Steve Wolfangel (swolfangel) Date: 2004-01-05 09:25 Message: Logged In: YES user_id=541224 I added the server.log file that contains the complete stack trace of the NoClassDefFound error. -- Comment By: Scott M Stark (starksm) Date: 2004-01-05 09:19 Message: Logged In: YES user_id=175228 The jdom.jar is only used by the XMBean parsing so as an immeadiate workaround just replace the top lib/jdom.jar with your version. Also, show the full stack trace for the
[JBoss-dev] [ jboss-Bugs-871035 ] Local interface bug
Bugs item #871035, was opened at 2004-01-05 10:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=871035&group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Vinh Nguyen (softwaremasters) Assigned to: Nobody/Anonymous (nobody) Summary: Local interface bug Initial Comment: I have entity beans with only local interfaces and session bean facades with only remote interfaces. Under 3.2.3, I kept getting the warning that no clustered invokers were defined for the entity beans. There was no warning for the session beans. When I also created remote interfaces for the entity beans, the warning messages went away. Also, after awhile, I can no longer find some of my entity beans through the local home interfaces. I haven't tried this with the remote home interfaces. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=871035&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-870942 ] Classloader problem with ear file
Bugs item #870942, was opened at 2004-01-05 06:54 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Wolfangel (swolfangel) Assigned to: Scott M Stark (starksm) Summary: Classloader problem with ear file Initial Comment: Hello, I have an ear file that contains 2 stateless session beans and all the 3rd party jars required by the beans. The 3rd party jars contain older jdom classes than the jdom jar included in the jboss lib dir. I have a unique classloader setup (in the jboss-app.xml file) but I am having problems with jdom. It is finding the jboss jdom classes instead of the ones included in the ear. when I change the jboss-app.xml file to contain the following lines: com.metamatrix:loader=MM.ear java2ParentDelegation=false I get a NoClassDefFoundError. java.lang.NoClassDefFoundError: java/sql/SQLException This class is in the rt.jar file in the jdk! I was under the impression that setting java2ParentDelegation to false meant that if the class was not found using the local classloader then the parent classloader would be called. In a nutshell, when I have java2ParentDelegation set to true, I get the jdom problem, when I have java2ParentDelegation set to false I am unable to see classes that are in the rt.jar file. Here is the output when starting the server. [Server] Starting JBoss (MX MicroKernel)... [Server] Release ID: JBoss [WonderLand] 3.2.3 (build: CVSTag=JBoss_3_2_3 date=200311301445) [Server] Home Dir: D:\mm40\jb32\server\jboss [Server] Home URL: file:/D:/mm40/jb32/server/jboss/ [Server] Library URL: file:/D:/mm40/jb32/server/jboss/lib/ [Server] Patch URL: null [Server] Server Name: metamatrix [Server] Server Home Dir: D:\mm40\jb32 \server\jboss\server\metamatrix [Server] Server Home URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/ [Server] Server Data Dir: D:\mm40\jb32 \server\jboss\server\metamatrix\data [Server] Server Temp Dir: D:\mm40\jb32 \server\jboss\server\metamatrix\tmp [Server] Server Config URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/conf/ [Server] Server Library URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/lib/ [Server] Root Deployment Filename: jboss-service.xml [Server] Starting General Purpose Architecture (GPA)... [ServerInfo] Java version: 1.4.2,Sun Microsystems Inc. [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.4.2-b28,Sun Microsystems Inc. [ServerInfo] OS-System: Windows XP 5.1,x86 -- >Comment By: Scott M Stark (starksm) Date: 2004-01-05 08:40 Message: Logged In: YES user_id=175228 Next step, add the following to the conf/log4j.xml and send me the resulting server.log and ucl.log zipped up as the ucl.log can be large: [EMAIL PROTECTED] -- Comment By: Scott M Stark (starksm) Date: 2004-01-05 08:33 Message: Logged In: YES user_id=175228 Yes, and there is a testcase in 3.2 for replacing the xml parser with a different version of xerces for example, using this approach. The problem with overriding the various xml related classes is that these are used all over and not all contexts are correctly limiting the scope of the classes they use. Presumably this is the case for the jdom usage. -- Comment By: Steve Wolfangel (swolfangel) Date: 2004-01-05 07:41 Message: Logged In: YES user_id=541224 Replacing the jdom.jar file got me past this problem. I am still interested in finding the correct solution since there is a chance I could have similar problems in the future. Am I correct by assuming that by setting up my own classloader and setting java2ParentDelegation to false in the jboss-app file is the correct approach? -- Comment By: Steve Wolfangel (swolfangel) Date: 2004-01-05 07:25 Message: Logged In: YES user_id=541224 I added the server.log file that contains the complete stack trace of the NoClassDefFound error. -- Comment By: Scott M Stark (starksm) Date: 2004-01-05 07:19 Message: Logged In: YES user_id=175228 The jdom.jar is only used by the XMBean parsing so as an immeadiate workaround just replace the top lib/jdom.jar with your version. Also, show the full stack trace for the NoClassDefFoundError on lookup of SQLException. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866
[JBoss-dev] [ jboss-Bugs-860337 ] Can't change database isolation mode since v3.2.2
Bugs item #860337, was opened at 2003-12-15 07:58 Message generated for change (Comment added) made by mring33621 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=860337&group_id=22866 Category: None Group: v3.2 Status: Open Resolution: None Priority: 9 Submitted By: Stéphane BOCQUET (sbocquet) Assigned to: Nobody/Anonymous (nobody) Summary: Can't change database isolation mode since v3.2.2 Initial Comment: OS : All JDK Version : Sun 1.4.1 Hi, I need to be in TRANSACTION_READ_COMMITTED with my EJB, but also have a DAO that need to be in TRANSACTION_READ_UNCOMMITTED, in order not to block the users during the SELECT statements (because of long EJB updates in the databases)... It seems that since the 3.2.2 version, the isolation level of a database connection cannot be changed (3.2.1 and 3.2.0 was possible !). The following code... myConnection.setTransactionIsolation (Connection.TRANSACTION_READ_UNCOMMITTED); ... returns an SQL isolation error : You cannot set isolation level during a managed transaction! -- Comment By: Matthew S. Ring (mring33621) Date: 2004-01-05 10:37 Message: Logged In: YES user_id=944195 I don't know if Sun's Specs say anything about this behavior, but this change is probably for safety. A workaround might be to have your DAOs use a separate DataSource to get their connections. That way, you're using 2 different factories to build 2 differently configured connections. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=860337&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-870942 ] Classloader problem with ear file
Bugs item #870942, was opened at 2004-01-05 06:54 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Wolfangel (swolfangel) Assigned to: Scott M Stark (starksm) Summary: Classloader problem with ear file Initial Comment: Hello, I have an ear file that contains 2 stateless session beans and all the 3rd party jars required by the beans. The 3rd party jars contain older jdom classes than the jdom jar included in the jboss lib dir. I have a unique classloader setup (in the jboss-app.xml file) but I am having problems with jdom. It is finding the jboss jdom classes instead of the ones included in the ear. when I change the jboss-app.xml file to contain the following lines: com.metamatrix:loader=MM.ear java2ParentDelegation=false I get a NoClassDefFoundError. java.lang.NoClassDefFoundError: java/sql/SQLException This class is in the rt.jar file in the jdk! I was under the impression that setting java2ParentDelegation to false meant that if the class was not found using the local classloader then the parent classloader would be called. In a nutshell, when I have java2ParentDelegation set to true, I get the jdom problem, when I have java2ParentDelegation set to false I am unable to see classes that are in the rt.jar file. Here is the output when starting the server. [Server] Starting JBoss (MX MicroKernel)... [Server] Release ID: JBoss [WonderLand] 3.2.3 (build: CVSTag=JBoss_3_2_3 date=200311301445) [Server] Home Dir: D:\mm40\jb32\server\jboss [Server] Home URL: file:/D:/mm40/jb32/server/jboss/ [Server] Library URL: file:/D:/mm40/jb32/server/jboss/lib/ [Server] Patch URL: null [Server] Server Name: metamatrix [Server] Server Home Dir: D:\mm40\jb32 \server\jboss\server\metamatrix [Server] Server Home URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/ [Server] Server Data Dir: D:\mm40\jb32 \server\jboss\server\metamatrix\data [Server] Server Temp Dir: D:\mm40\jb32 \server\jboss\server\metamatrix\tmp [Server] Server Config URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/conf/ [Server] Server Library URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/lib/ [Server] Root Deployment Filename: jboss-service.xml [Server] Starting General Purpose Architecture (GPA)... [ServerInfo] Java version: 1.4.2,Sun Microsystems Inc. [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.4.2-b28,Sun Microsystems Inc. [ServerInfo] OS-System: Windows XP 5.1,x86 -- >Comment By: Scott M Stark (starksm) Date: 2004-01-05 08:33 Message: Logged In: YES user_id=175228 Yes, and there is a testcase in 3.2 for replacing the xml parser with a different version of xerces for example, using this approach. The problem with overriding the various xml related classes is that these are used all over and not all contexts are correctly limiting the scope of the classes they use. Presumably this is the case for the jdom usage. -- Comment By: Steve Wolfangel (swolfangel) Date: 2004-01-05 07:41 Message: Logged In: YES user_id=541224 Replacing the jdom.jar file got me past this problem. I am still interested in finding the correct solution since there is a chance I could have similar problems in the future. Am I correct by assuming that by setting up my own classloader and setting java2ParentDelegation to false in the jboss-app file is the correct approach? -- Comment By: Steve Wolfangel (swolfangel) Date: 2004-01-05 07:25 Message: Logged In: YES user_id=541224 I added the server.log file that contains the complete stack trace of the NoClassDefFound error. -- Comment By: Scott M Stark (starksm) Date: 2004-01-05 07:19 Message: Logged In: YES user_id=175228 The jdom.jar is only used by the XMBean parsing so as an immeadiate workaround just replace the top lib/jdom.jar with your version. Also, show the full stack trace for the NoClassDefFoundError on lookup of SQLException. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list
[JBoss-dev] What is this codeblock in BasicMBeanRegistry
org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean
is the following codeblock:
// This is a fix for the SAR TCL problem in 4.0
// Allow the classloader in the value map to be an ObjectName
if (valueMap != null)
{
Object obj = valueMap.get(CLASSLOADER);
if (obj != null && obj instanceof ObjectName)
{
MBeanEntry clEntry = null;
try
{
clEntry = get((ObjectName) obj);
}
catch (InstanceNotFoundException e)
{
throw new RuntimeOperationsException(
new IllegalArgumentException(e.toString()));
}
valueMap.put(CLASSLOADER, clEntry.getResourceInstance());
}
}
What is this for? The following dispatch to the invokePreRegister is
not using the correct thread context class loader. It needs to be using
the class loader of the mbean being registered so that any scoped
classes
that are loaded as part of the registration are available. I'm
correcting
this, but I need to know what the source of this duality of type is.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-870942 ] Classloader problem with ear file
Bugs item #870942, was opened at 2004-01-05 08:54 Message generated for change (Comment added) made by swolfangel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Wolfangel (swolfangel) Assigned to: Scott M Stark (starksm) Summary: Classloader problem with ear file Initial Comment: Hello, I have an ear file that contains 2 stateless session beans and all the 3rd party jars required by the beans. The 3rd party jars contain older jdom classes than the jdom jar included in the jboss lib dir. I have a unique classloader setup (in the jboss-app.xml file) but I am having problems with jdom. It is finding the jboss jdom classes instead of the ones included in the ear. when I change the jboss-app.xml file to contain the following lines: com.metamatrix:loader=MM.ear java2ParentDelegation=false I get a NoClassDefFoundError. java.lang.NoClassDefFoundError: java/sql/SQLException This class is in the rt.jar file in the jdk! I was under the impression that setting java2ParentDelegation to false meant that if the class was not found using the local classloader then the parent classloader would be called. In a nutshell, when I have java2ParentDelegation set to true, I get the jdom problem, when I have java2ParentDelegation set to false I am unable to see classes that are in the rt.jar file. Here is the output when starting the server. [Server] Starting JBoss (MX MicroKernel)... [Server] Release ID: JBoss [WonderLand] 3.2.3 (build: CVSTag=JBoss_3_2_3 date=200311301445) [Server] Home Dir: D:\mm40\jb32\server\jboss [Server] Home URL: file:/D:/mm40/jb32/server/jboss/ [Server] Library URL: file:/D:/mm40/jb32/server/jboss/lib/ [Server] Patch URL: null [Server] Server Name: metamatrix [Server] Server Home Dir: D:\mm40\jb32 \server\jboss\server\metamatrix [Server] Server Home URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/ [Server] Server Data Dir: D:\mm40\jb32 \server\jboss\server\metamatrix\data [Server] Server Temp Dir: D:\mm40\jb32 \server\jboss\server\metamatrix\tmp [Server] Server Config URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/conf/ [Server] Server Library URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/lib/ [Server] Root Deployment Filename: jboss-service.xml [Server] Starting General Purpose Architecture (GPA)... [ServerInfo] Java version: 1.4.2,Sun Microsystems Inc. [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.4.2-b28,Sun Microsystems Inc. [ServerInfo] OS-System: Windows XP 5.1,x86 -- >Comment By: Steve Wolfangel (swolfangel) Date: 2004-01-05 09:41 Message: Logged In: YES user_id=541224 Replacing the jdom.jar file got me past this problem. I am still interested in finding the correct solution since there is a chance I could have similar problems in the future. Am I correct by assuming that by setting up my own classloader and setting java2ParentDelegation to false in the jboss-app file is the correct approach? -- Comment By: Steve Wolfangel (swolfangel) Date: 2004-01-05 09:25 Message: Logged In: YES user_id=541224 I added the server.log file that contains the complete stack trace of the NoClassDefFound error. -- Comment By: Scott M Stark (starksm) Date: 2004-01-05 09:19 Message: Logged In: YES user_id=175228 The jdom.jar is only used by the XMBean parsing so as an immeadiate workaround just replace the top lib/jdom.jar with your version. Also, show the full stack trace for the NoClassDefFoundError on lookup of SQLException. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-870942 ] Classloader problem with ear file
Bugs item #870942, was opened at 2004-01-05 08:54 Message generated for change (Comment added) made by swolfangel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866 Category: JBossMX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Wolfangel (swolfangel) Assigned to: Scott M Stark (starksm) Summary: Classloader problem with ear file Initial Comment: Hello, I have an ear file that contains 2 stateless session beans and all the 3rd party jars required by the beans. The 3rd party jars contain older jdom classes than the jdom jar included in the jboss lib dir. I have a unique classloader setup (in the jboss-app.xml file) but I am having problems with jdom. It is finding the jboss jdom classes instead of the ones included in the ear. when I change the jboss-app.xml file to contain the following lines: com.metamatrix:loader=MM.ear java2ParentDelegation=false I get a NoClassDefFoundError. java.lang.NoClassDefFoundError: java/sql/SQLException This class is in the rt.jar file in the jdk! I was under the impression that setting java2ParentDelegation to false meant that if the class was not found using the local classloader then the parent classloader would be called. In a nutshell, when I have java2ParentDelegation set to true, I get the jdom problem, when I have java2ParentDelegation set to false I am unable to see classes that are in the rt.jar file. Here is the output when starting the server. [Server] Starting JBoss (MX MicroKernel)... [Server] Release ID: JBoss [WonderLand] 3.2.3 (build: CVSTag=JBoss_3_2_3 date=200311301445) [Server] Home Dir: D:\mm40\jb32\server\jboss [Server] Home URL: file:/D:/mm40/jb32/server/jboss/ [Server] Library URL: file:/D:/mm40/jb32/server/jboss/lib/ [Server] Patch URL: null [Server] Server Name: metamatrix [Server] Server Home Dir: D:\mm40\jb32 \server\jboss\server\metamatrix [Server] Server Home URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/ [Server] Server Data Dir: D:\mm40\jb32 \server\jboss\server\metamatrix\data [Server] Server Temp Dir: D:\mm40\jb32 \server\jboss\server\metamatrix\tmp [Server] Server Config URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/conf/ [Server] Server Library URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/lib/ [Server] Root Deployment Filename: jboss-service.xml [Server] Starting General Purpose Architecture (GPA)... [ServerInfo] Java version: 1.4.2,Sun Microsystems Inc. [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.4.2-b28,Sun Microsystems Inc. [ServerInfo] OS-System: Windows XP 5.1,x86 -- >Comment By: Steve Wolfangel (swolfangel) Date: 2004-01-05 09:25 Message: Logged In: YES user_id=541224 I added the server.log file that contains the complete stack trace of the NoClassDefFound error. -- Comment By: Scott M Stark (starksm) Date: 2004-01-05 09:19 Message: Logged In: YES user_id=175228 The jdom.jar is only used by the XMBean parsing so as an immeadiate workaround just replace the top lib/jdom.jar with your version. Also, show the full stack trace for the NoClassDefFoundError on lookup of SQLException. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-870942 ] Classloader problem with ear file
Bugs item #870942, was opened at 2004-01-05 06:54 Message generated for change (Comment added) made by starksm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866 >Category: JBossMX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Wolfangel (swolfangel) >Assigned to: Scott M Stark (starksm) Summary: Classloader problem with ear file Initial Comment: Hello, I have an ear file that contains 2 stateless session beans and all the 3rd party jars required by the beans. The 3rd party jars contain older jdom classes than the jdom jar included in the jboss lib dir. I have a unique classloader setup (in the jboss-app.xml file) but I am having problems with jdom. It is finding the jboss jdom classes instead of the ones included in the ear. when I change the jboss-app.xml file to contain the following lines: com.metamatrix:loader=MM.ear java2ParentDelegation=false I get a NoClassDefFoundError. java.lang.NoClassDefFoundError: java/sql/SQLException This class is in the rt.jar file in the jdk! I was under the impression that setting java2ParentDelegation to false meant that if the class was not found using the local classloader then the parent classloader would be called. In a nutshell, when I have java2ParentDelegation set to true, I get the jdom problem, when I have java2ParentDelegation set to false I am unable to see classes that are in the rt.jar file. Here is the output when starting the server. [Server] Starting JBoss (MX MicroKernel)... [Server] Release ID: JBoss [WonderLand] 3.2.3 (build: CVSTag=JBoss_3_2_3 date=200311301445) [Server] Home Dir: D:\mm40\jb32\server\jboss [Server] Home URL: file:/D:/mm40/jb32/server/jboss/ [Server] Library URL: file:/D:/mm40/jb32/server/jboss/lib/ [Server] Patch URL: null [Server] Server Name: metamatrix [Server] Server Home Dir: D:\mm40\jb32 \server\jboss\server\metamatrix [Server] Server Home URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/ [Server] Server Data Dir: D:\mm40\jb32 \server\jboss\server\metamatrix\data [Server] Server Temp Dir: D:\mm40\jb32 \server\jboss\server\metamatrix\tmp [Server] Server Config URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/conf/ [Server] Server Library URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/lib/ [Server] Root Deployment Filename: jboss-service.xml [Server] Starting General Purpose Architecture (GPA)... [ServerInfo] Java version: 1.4.2,Sun Microsystems Inc. [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.4.2-b28,Sun Microsystems Inc. [ServerInfo] OS-System: Windows XP 5.1,x86 -- >Comment By: Scott M Stark (starksm) Date: 2004-01-05 07:19 Message: Logged In: YES user_id=175228 The jdom.jar is only used by the XMBean parsing so as an immeadiate workaround just replace the top lib/jdom.jar with your version. Also, show the full stack trace for the NoClassDefFoundError on lookup of SQLException. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-870942 ] Classloader problem with ear file
Bugs item #870942, was opened at 2004-01-05 08:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Steve Wolfangel (swolfangel) Assigned to: Nobody/Anonymous (nobody) Summary: Classloader problem with ear file Initial Comment: Hello, I have an ear file that contains 2 stateless session beans and all the 3rd party jars required by the beans. The 3rd party jars contain older jdom classes than the jdom jar included in the jboss lib dir. I have a unique classloader setup (in the jboss-app.xml file) but I am having problems with jdom. It is finding the jboss jdom classes instead of the ones included in the ear. when I change the jboss-app.xml file to contain the following lines: com.metamatrix:loader=MM.ear java2ParentDelegation=false I get a NoClassDefFoundError. java.lang.NoClassDefFoundError: java/sql/SQLException This class is in the rt.jar file in the jdk! I was under the impression that setting java2ParentDelegation to false meant that if the class was not found using the local classloader then the parent classloader would be called. In a nutshell, when I have java2ParentDelegation set to true, I get the jdom problem, when I have java2ParentDelegation set to false I am unable to see classes that are in the rt.jar file. Here is the output when starting the server. [Server] Starting JBoss (MX MicroKernel)... [Server] Release ID: JBoss [WonderLand] 3.2.3 (build: CVSTag=JBoss_3_2_3 date=200311301445) [Server] Home Dir: D:\mm40\jb32\server\jboss [Server] Home URL: file:/D:/mm40/jb32/server/jboss/ [Server] Library URL: file:/D:/mm40/jb32/server/jboss/lib/ [Server] Patch URL: null [Server] Server Name: metamatrix [Server] Server Home Dir: D:\mm40\jb32 \server\jboss\server\metamatrix [Server] Server Home URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/ [Server] Server Data Dir: D:\mm40\jb32 \server\jboss\server\metamatrix\data [Server] Server Temp Dir: D:\mm40\jb32 \server\jboss\server\metamatrix\tmp [Server] Server Config URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/conf/ [Server] Server Library URL: file:/D:/mm40/jb32/server/jboss/server/metamatrix/lib/ [Server] Root Deployment Filename: jboss-service.xml [Server] Starting General Purpose Architecture (GPA)... [ServerInfo] Java version: 1.4.2,Sun Microsystems Inc. [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.4.2-b28,Sun Microsystems Inc. [ServerInfo] OS-System: Windows XP 5.1,x86 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870942&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 5-January-2004
Empty SELECT clause. I will look at it. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Scott M Stark > Sent: Monday, January 05, 2004 4:32 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Automated JBoss(Branch_3_2 > WonderLand) Testsuite Results: 5-January-2004 > > What are these exceptions showing up in the > org.jboss.test.deadlock.test.BeanStressTestCase? > > 06:25:53,725 ERROR [LogInterceptor] EJBException, causedBy: > java.sql.SQLException: Unexpected token: FROM in statement > [SELECT FROM NEXTGENREENTNOTSUP WHERE (name='1')] > at org.hsqldb.Trace.getError(Unknown Source) > at org.hsqldb.jdbcResultSet.(Unknown Source) > at org.hsqldb.jdbcConnection.executeStandalone(Unknown Source) > at org.hsqldb.jdbcConnection.execute(Unknown Source) > at org.hsqldb.jdbcStatement.fetchResult(Unknown Source) > at org.hsqldb.jdbcStatement.executeQuery(Unknown Source) > at > org.hsqldb.jdbcPreparedStatement.executeQuery(Unknown Source) > at > org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.execu > teQuery(Wr > appedPreparedStatement.java:304) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(J > DBCLoadEnt > ityCommand.java:155) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(J > DBCLoadEnt > ityCommand.java:72) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDB > CStoreMana > ger.java:620) > at > org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDB > CStoreMana > ger.java:602) > at > org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPers > istenceMan > ager.java:381) > > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of [EMAIL PROTECTED] > Sent: Monday, January 05, 2004 6:28 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite > Results: 5-January-2004 > > Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: > 5-January-2004 > > > JBoss daily test results > > SUMMARY > > Number of tests run: 1633 > > > > Successful tests: 1598 > > Errors:22 > > Failures: 13 > > > > > > --- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign > up for IBM's Free Linux Tutorials. Learn everything from the > bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=ick > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 5-January-2004
What are these exceptions showing up in the org.jboss.test.deadlock.test.BeanStressTestCase? 06:25:53,725 ERROR [LogInterceptor] EJBException, causedBy: java.sql.SQLException: Unexpected token: FROM in statement [SELECT FROM NEXTGENREENTNOTSUP WHERE (name='1')] at org.hsqldb.Trace.getError(Unknown Source) at org.hsqldb.jdbcResultSet.(Unknown Source) at org.hsqldb.jdbcConnection.executeStandalone(Unknown Source) at org.hsqldb.jdbcConnection.execute(Unknown Source) at org.hsqldb.jdbcStatement.fetchResult(Unknown Source) at org.hsqldb.jdbcStatement.executeQuery(Unknown Source) at org.hsqldb.jdbcPreparedStatement.executeQuery(Unknown Source) at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(Wr appedPreparedStatement.java:304) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEnt ityCommand.java:155) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEnt ityCommand.java:72) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreMana ger.java:620) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreMana ger.java:602) at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceMan ager.java:381) Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, January 05, 2004 6:28 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 5-January-2004 Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 5-January-2004 JBoss daily test results SUMMARY Number of tests run: 1633 Successful tests: 1598 Errors:22 Failures: 13 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] InstanceCache - NoSuchObjectException
My taste tells me to throw JBoss-specific object not found exception and handle it according to the invocation type in the place get() was called. Another way would be to add getLocal() method to InstanceCache (implementation) that would throw NoSuchObjectLocalException. But it's not nice because as you wrote the cache should not be aware of this. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Adrian Brock > Sent: Monday, January 05, 2004 3:28 PM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] InstanceCache - NoSuchObjectException > > The interface org.jboss.ejb.plugins.InstanceCache > mandates NoSuchObjectException for bean not found. > > This is incorrect for local invocations and leads to an > EJBException wrapping the exception. > > Since the cache knows nothing about local/remote the obvious > fix is to "unwrap" the NoSuchObjectException and recreate it > as a NoSuchObjectLocalException wherever get() is used. > > Anybody see another way of doing this? > > Regards, > Adrian > -- > > Adrian Brock > Director of Support > Back Office > JBoss Group, LLC > --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] InstanceCache - NoSuchObjectException
Aside from fixing the interface to not be ejb1.1 specific, no. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Monday, January 05, 2004 5:28 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] InstanceCache - NoSuchObjectException The interface org.jboss.ejb.plugins.InstanceCache mandates NoSuchObjectException for bean not found. This is incorrect for local invocations and leads to an EJBException wrapping the exception. Since the cache knows nothing about local/remote the obvious fix is to "unwrap" the NoSuchObjectException and recreate it as a NoSuchObjectLocalException wherever get() is used. Anybody see another way of doing this? Regards, Adrian -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 5-January-2004
Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 5-January-2004 JBoss daily test results SUMMARY Number of tests run: 1633 Successful tests: 1598 Errors:22 Failures: 13 [time of test: 2004-01-05.14-25 GMT] [java.version: 1.4.2] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.2-b28] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.20-9smp] Useful resources: - http://jboss.sourceforge.net//junit-results/32/2004-01-05.14-25 for the junit report 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: TxConcurrentUnitTestCase Test:testConcurrentAccess Type:failure Exception: junit.framework.AssertionFailedError Message: expected:<262> but was:<1000> - Suite: StatefulSessionUnitTestCase Test:testStrictPooling Type:failure Exception: junit.framework.AssertionFailedError Message: SessionInvoker.runEx != null - Suite: EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionInTxMarkRollback_remote Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionNewTxMarkRollback_remote Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionInTxMarkRollback_local Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: EntityExceptionUnitTestCase Test:testNotDiscardedApplicationExceptionNewTxMarkRollback_local Type:error Exception: net.sourceforge.junitejb.RemoteTestException Message: Error, bean instance was discarded! - Suite: DeployXMBeanUnitTestCase Test:testUserXMBeanPersistentValues Type:failure Exception: junit.framework.AssertionFailedError Message: value == UpdatedAttr1Value, value=Att1InitialValue - Suite: JMXInvokerUnitTestCase Test:testGetSomething Type:error Exception: javax.management.InstanceNotFoundException Message: jboss.test:service=InvokerTest is not registered. - Suite: JMXInvokerUnitTestCase Test:testGetCustom Type:error Exception: javax.management.InstanceNotFoundException Message: jboss.test:service=InvokerTest is not registered. - Suite: JMXInvokerUnitTestCase Test:testSetCustom Type:error Exception: javax.management.MBeanException Message: javax.management.InstanceNotFoundException: jboss.test:service=InvokerTest is not registered. - Suite: JMXInvokerUnitTestCase Test:testNotification Type:error Exception: java.lang.reflect.UndeclaredThrowableException Message: - Suite: JMXInvokerUnitTestCase Test:testServerFound Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/cvs/JBoss3.2/jboss-3.2/build/output/jboss-3.2.4RC1/server/all/tmp/deploy/tmp38612invoker-adaptor-test.ear-contents/invoker-adaptor-test.sar; - nested throwable: (org.jboss.deployment.DeploymentException: No ClassLoaders found for: org.jboss.test.jmx.interceptors.PrincipalInterceptor; - nested throwable: (java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.test.jmx.interceptors.PrincipalInterceptor)) - Suite: ProxyUnitTestCase Test:testStarted Type:failure Exception: junit.framework.AssertionFailedError Message: Proxy tests should be started - Suite: ProxyUnitTestCase Test:testServerFound Type:error Exception: org.jboss.deployment.IncompleteDeploymentException Message: - Suite: SecureJMXInvokerUnitTestCase Test:testGetSomething Type:error Exception: javax.management.InstanceNotFoundException Message:
[JBoss-dev] InstanceCache - NoSuchObjectException
The interface org.jboss.ejb.plugins.InstanceCache mandates NoSuchObjectException for bean not found. This is incorrect for local invocations and leads to an EJBException wrapping the exception. Since the cache knows nothing about local/remote the obvious fix is to "unwrap" the NoSuchObjectException and recreate it as a NoSuchObjectLocalException wherever get() is used. Anybody see another way of doing this? Regards, Adrian -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-870874 ] Unmatched tags mess up screen layout
Bugs item #870874, was opened at 2004-01-05 13:37 Message generated for change (Comment added) made by cooperfbi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870874&group_id=22866 Category: Nukes Group: None Status: Open Resolution: None Priority: 5 Submitted By: Juha Lindfors (juhalindfors) Assigned to: Julien Viet (cooperfbi) Summary: Unmatched tags mess up screen layout Initial Comment: Our current website, Mozilla 1.5 Posting the following content results in poor HTML page layout: [quote]somethign something[/quote] [/quote] Example here: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3817378#3817378 -- >Comment By: Julien Viet (cooperfbi) Date: 2004-01-05 14:00 Message: Logged In: YES user_id=337141 yes the current code parser only translate code to html, it does not check wellfomdness. I am porting stuff from the forums to nukes for general purpose usage and I have already rewritten that part so now it ensure wellformdess of the tags. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870874&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ModelMBean persistence appears broken
Its his persistence implementation that cannot work with the duplication of descriptors as this is what I modified and used for the 3.2.3 and earlier persistence tests. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha Lindfors Sent: Monday, January 05, 2004 4:51 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ModelMBean persistence appears broken If there are no unit tests for the persistence in the HEAD test suite then it hasn't. I can't remember if Matt Munz added any tests for his persistence implementation or not. -- Juha --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ModelMBean persistence appears broken
If there are no unit tests for the persistence in the HEAD test suite then it hasn't. I can't remember if Matt Munz added any tests for his persistence implementation or not. -- Juha On Mon, 5 Jan 2004, Scott M Stark wrote: > Another problem I'm seeing with the change in interceptors is that > the invocation context associated with attribute interceptors is using > a copy of the ModelMBeanAttributeInfo descriptor, and this is what the > ModelMBeanAttributeInterceptor is updating. However, the > PersistenceInterceptor > simply calls the ModelMBeanInvoker through its PersistentMBean.store() > method > to write out the changed values. However, the ModelMBeanInvoker > attribute > VALUE descriptors have not been modified, and so the current persistence > manager implementation does not work. The cached attribute values are > also local copies in the various interceptors. There is not any way to > obtain the descriptor refence from the current ModelMBeanAttributeInfo > as it only supports a getDescriptor() method which returns a copy of the > descriptor. How has the ModelMBean persistence been tested? > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > > --- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id78&alloc_id371&opÌk > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-870874 ] Unmatched tags mess up screen layout
Bugs item #870874, was opened at 2004-01-05 14:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870874&group_id=22866 Category: Nukes Group: None Status: Open Resolution: None Priority: 5 Submitted By: Juha Lindfors (juhalindfors) Assigned to: Julien Viet (cooperfbi) Summary: Unmatched tags mess up screen layout Initial Comment: Our current website, Mozilla 1.5 Posting the following content results in poor HTML page layout: [quote]somethign something[/quote] [/quote] Example here: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3817378#3817378 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=870874&group_id=22866 --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] ModelMBean persistence appears broken
Another problem I'm seeing with the change in interceptors is that the invocation context associated with attribute interceptors is using a copy of the ModelMBeanAttributeInfo descriptor, and this is what the ModelMBeanAttributeInterceptor is updating. However, the PersistenceInterceptor simply calls the ModelMBeanInvoker through its PersistentMBean.store() method to write out the changed values. However, the ModelMBeanInvoker attribute VALUE descriptors have not been modified, and so the current persistence manager implementation does not work. The cached attribute values are also local copies in the various interceptors. There is not any way to obtain the descriptor refence from the current ModelMBeanAttributeInfo as it only supports a getDescriptor() method which returns a copy of the descriptor. How has the ModelMBean persistence been tested? Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Change XMBean constants case?
Right, but we are not talking about ModelMBean descriptor fields, rather the JBoss specific XMBean implementation. Its attributes the map to descriptor fields are case sensitive. Because of this I'm saying the constants should be case sensitive, and since all lookups of descriptor fields are done in a case insensitive manner, this only affects the XMBean. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Monday, January 05, 2004 3:54 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Change XMBean constants case? On Mon, 2004-01-05 at 11:45, Juha Lindfors wrote: > You should check the 1.2 spec and see if they've made a decision on > the case of the attribute names. > > -- Juha > Page 96 in "Predefined Descriptor Fields" "Field names are not case sensitive. The field descriptorType can also be referred to as DescriptorType or DESCRIPTORTYPE. The case used when a descriptor is created or updated is preserved. It is recommended that the form shown here be used consistently." So the case is unimportant. The only requirement is to preserve the case externally. Regards, Adrian --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Change XMBean constants case?
On Mon, 2004-01-05 at 11:45, Juha Lindfors wrote: > You should check the 1.2 spec and see if they've made a decision on the > case of the attribute names. > > -- Juha > Page 96 in "Predefined Descriptor Fields" "Field names are not case sensitive. The field descriptorType can also be referred to as DescriptorType or DESCRIPTORTYPE. The case used when a descriptor is created or updated is preserved. It is recommended that the form shown here be used consistently." So the case is unimportant. The only requirement is to preserve the case externally. Regards, Adrian > > On Mon, 5 Jan 2004, Scott M Stark wrote: > > > The required ModelMBean destriptor fields like persistPolicy, > > persistPeriod, > > currencyTimeLimit are defined in ModelMBeanConstants as lower case > > values. > > These constants are used when parsing the XMBean xml descriptor > > attributes > > which need to be the case sensitive strings. Since these are converted > > to > > lowercase for the field lookups, why aren't the constants still being > > defined with the proper case? I'm changing this in the 3.2 version, > > shouldn't > > this be done on head as well? > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > > --- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Change XMBean constants case?
You should check the 1.2 spec and see if they've made a decision on the case of the attribute names. -- Juha On Mon, 5 Jan 2004, Scott M Stark wrote: > The required ModelMBean destriptor fields like persistPolicy, > persistPeriod, > currencyTimeLimit are defined in ModelMBeanConstants as lower case > values. > These constants are used when parsing the XMBean xml descriptor > attributes > which need to be the case sensitive strings. Since these are converted > to > lowercase for the field lookups, why aren't the constants still being > defined with the proper case? I'm changing this in the 3.2 version, > shouldn't > this be done on head as well? > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Change XMBean constants case?
The required ModelMBean destriptor fields like persistPolicy, persistPeriod, currencyTimeLimit are defined in ModelMBeanConstants as lower case values. These constants are used when parsing the XMBean xml descriptor attributes which need to be the case sensitive strings. Since these are converted to lowercase for the field lookups, why aren't the constants still being defined with the proper case? I'm changing this in the 3.2 version, shouldn't this be done on head as well? Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Change in XMBean interceptors
The new XMBean has interceptors at the mbean, attribute and operation level whereas the previous version only had interceptors at the mbean level and these were the interceptors seen for operations and attribute access. For backward compatbility with the 3.2.3 and earlier XMBean, any mbean level interceptors are going to have to be the default operation and attribute interceptors. Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
