[JBoss-dev] [JBoss JIRA] Resolved: (JBREM-53) Problem during classloading on certain classloaders
[ http://jira.jboss.com/jira/browse/JBREM-53?page=history ] Jeff Haynie resolved JBREM-53: -- Resolution: Done committed to Branch_3_2 > Problem during classloading on certain classloaders > --- > > Key: JBREM-53 > URL: http://jira.jboss.com/jira/browse/JBREM-53 > Project: JBoss Remoting > Type: Bug > Reporter: Jeff Haynie > Assignee: Jeff Haynie > > > Problem in ClassByteClassLoader.findClass recursion on certain classes in > certain classloaders which will cause a stack overflow because findClass > calls super.loadClass unnecessarily. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-53) Problem during classloading on certain classloaders
Problem during classloading on certain classloaders --- Key: JBREM-53 URL: http://jira.jboss.com/jira/browse/JBREM-53 Project: JBoss Remoting Type: Bug Reporter: Jeff Haynie Assigned to: Jeff Haynie Problem in ClassByteClassLoader.findClass recursion on certain classes in certain classloaders which will cause a stack overflow because findClass calls super.loadClass unnecessarily. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBREM-49) Problem with loading an array class remotely
[ http://jira.jboss.com/jira/browse/JBREM-49?page=history ] Jeff Haynie closed JBREM-49: Resolution: Done Committed to Branch_3_2 > Problem with loading an array class remotely > > > Key: JBREM-49 > URL: http://jira.jboss.com/jira/browse/JBREM-49 > Project: JBoss Remoting > Type: Bug > Reporter: Jeff Haynie > Assignee: Jeff Haynie > > Time Spent: 2 hours >Remaining: 0 minutes > > Problem when you try and load an array class such as: > [LFooBar; > Will not properly load and define the class and will throw a class not found > back to the remote side which will give some weird messages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-49) Problem with loading an array class remotely
Problem with loading an array class remotely Key: JBREM-49 URL: http://jira.jboss.com/jira/browse/JBREM-49 Project: JBoss Remoting Type: Bug Reporter: Jeff Haynie Assigned to: Tom Elrod Problem when you try and load an array class such as: [LFooBar; Will not properly load and define the class and will throw a class not found back to the remote side which will give some weird messages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] New JBoss Monitoring services
The java wrapper uses native code to start the JVM and handles natively restart, etc. You basically implement simple Java class that has a start and stop method and we just then call the appropriate method in Server to control jboss - which then goes through the normal lifecycle. The trick, however, is to continue to notify the service controller of your status -- which the java wrapper stuff exposes a java method to give him hints on start / stop status. This is important in windows services to get the appopriate status and to make sure the Windows Service Manager doesn't think you're ignoring him. Jeff Ivelin Ivanov wrote: Would it use native code to restart the JBoss services or would it just ask the deployers to undeploy and redeploy all services? Ivelin --- Jeff Haynie <[EMAIL PROTECTED]> wrote: We use http://wrapper.tanukisoftware.org/doc/english/ with JBoss on both Windows and Linux and it handles all of this out-of-the-box (restart failure, retry logic, etc.) I would recommend it instead of rolling your own. They've even got a MBean for managing restarts, etc. I'll be glad to contribute / patch our jboss startup/shutdown wrapper around ServerImpl that controls the service manager lifecycle if it would help. Jeff Ivelin Ivanov wrote: --- 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] New JBoss Monitoring services
We also have written a native (via JNI) library for getting all the system level information such as CPU load, handles, threads, memory, etc. and we have a framework that fires JMX snapshot notifications (configurable). Our management server then monitors these snapshots and our analytics server records them in a DB for trending. Our management GUI (in Swing) can display near real-time machine information for each jboss server on the network - all with graphing, etc. much like task manager in Windows. I can potentially contribute some of this if helpful too. Jeff Ivelin Ivanov wrote: Very nice, Bill. Email notifications when memoty is low will be very useful. Is there a CPU utilization monitor as well? Scott and I talked some time ago about a heart watch service which will restart the server when the memory is too low or the CPU is pegged for too long. Your work will be of help. Do you have some thoughts what is an appropriate way to restart the server. Not restart the JVM, but just undeploy everything and deploy it again. Ivelin --- Jae Gangemi <[EMAIL PROTECTED]> wrote: agreed - i can't wait to start playing w/ it. any proposed ETA for 3.2.4? -jae -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Sabrin Sent: Tuesday, January 06, 2004 3:00 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] New JBoss Monitoring services Well done Bill, this is good stuff:) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, December 12, 2003 4:24 PM To: Jboss-Dev; JBoss 2; [EMAIL PROTECTED] Subject: [JBoss-dev] New JBoss Monitoring services This will be released in JBoss 3.2.4, but it is now available in 3.2 branch: cvs checkout -r Branch_3_2 jboss-3.2 I've also attached some screen shots JBoss Monitoring In JBoss 3.2.4, we've implemented some new JMX MBean monitoring and a nice GUI around this infrastructure as well as a way to plug in how alerts are processed. Why didn't we use the JMX Gauge and String monitors that come implemented with the JMX spec? 3 reasons: 1. They are not integrated with our Service architecture 2. They have no way of determining which monitors have sent an alert and are currently disabled because an alert was reached 3. They have no way of reseting an alert So, what infrastructure have we built? First let's look at configuring a JMX MBean monitor through the plain old -service.xml interface that you would to create any MBean. All Monitors are MBeans that start a thread to watch the values of another MBean's attribute. When a monitoring threshold is reached, the MOnitor will send out an MBean Notification to a set of registered listeners. Currently in JBoss, the are two types of listeners, a dumb Console listener, and an Email listener which will send out an email whenever an alert is received. Of course, the messages are fully configurable. Numeric Attribute Monitors The first type of monitor is a org.jboss.monitor.ThresholdMonitor that is used to track Numberic MBean attributes. Here is an example configuration of a monitor of free available memory. It will send a JMX Notification when free memory goes below one megabyte. The MBean it is watching over that has this particular stat is jboss.system:type=ServerInfo. File: FreeMemory_Monitor-service.xml FreeMemory Monitor name="ObservedObject">jboss.system:type=ServerInfo FreeMemory 100 1 1000 true jboss.alerts:service=ConsoleAlertListener -list-element> jboss.alerts:service=EmailAlertListener ist-element> Let's walk through each attribute: FreeMemory The display name in which this monitor will be shown in the web-console. If you create monitors by hand you can have it managed by the web-console if you have one monitor defined in one file only and the name of the file is the same name as the monitor and the file lives in ./deploy/management/monitors/ So The above example the filename should be FreeMemory_Monitor-service.xml, notice that whitespace is substituted with an '_' charater. name="ObservedObject">jboss.system:type=ServerInfo FreeMemory These are the MBean and the MBean attribute this monitor will watch. If the MBean is a ServiceMBean then you should make this a so that this monitor doesn't start before the watched MBean is loaded. 100 1 The Threshold is the value threshold of the attribute. The CompareTo is a numeric value, -1 means > (greater than), 0 means = (equal), 1 means (less than). These are the same values used by Java comparators. So in this example, when the FreeMemory attribute is less than 100 a JMX notification will be sent. 1000 The MBean creates a thread that will wake up every so often to check the threshold against the MBean attribute it is watching. The Period is the time in milliseconds this thread will sleep. true Enabled determi
Re: [JBoss-dev] New JBoss Monitoring services
We use http://wrapper.tanukisoftware.org/doc/english/ with JBoss on both Windows and Linux and it handles all of this out-of-the-box (restart failure, retry logic, etc.) I would recommend it instead of rolling your own. They've even got a MBean for managing restarts, etc. I'll be glad to contribute / patch our jboss startup/shutdown wrapper around ServerImpl that controls the service manager lifecycle if it would help. Jeff Ivelin Ivanov wrote: Very nice, Bill. Email notifications when memoty is low will be very useful. Is there a CPU utilization monitor as well? Scott and I talked some time ago about a heart watch service which will restart the server when the memory is too low or the CPU is pegged for too long. Your work will be of help. Do you have some thoughts what is an appropriate way to restart the server. Not restart the JVM, but just undeploy everything and deploy it again. Ivelin --- Jae Gangemi <[EMAIL PROTECTED]> wrote: agreed - i can't wait to start playing w/ it. any proposed ETA for 3.2.4? -jae -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Sabrin Sent: Tuesday, January 06, 2004 3:00 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] New JBoss Monitoring services Well done Bill, this is good stuff:) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, December 12, 2003 4:24 PM To: Jboss-Dev; JBoss 2; [EMAIL PROTECTED] Subject: [JBoss-dev] New JBoss Monitoring services This will be released in JBoss 3.2.4, but it is now available in 3.2 branch: cvs checkout -r Branch_3_2 jboss-3.2 I've also attached some screen shots JBoss Monitoring In JBoss 3.2.4, we've implemented some new JMX MBean monitoring and a nice GUI around this infrastructure as well as a way to plug in how alerts are processed. Why didn't we use the JMX Gauge and String monitors that come implemented with the JMX spec? 3 reasons: 1. They are not integrated with our Service architecture 2. They have no way of determining which monitors have sent an alert and are currently disabled because an alert was reached 3. They have no way of reseting an alert So, what infrastructure have we built? First let's look at configuring a JMX MBean monitor through the plain old -service.xml interface that you would to create any MBean. All Monitors are MBeans that start a thread to watch the values of another MBean's attribute. When a monitoring threshold is reached, the MOnitor will send out an MBean Notification to a set of registered listeners. Currently in JBoss, the are two types of listeners, a dumb Console listener, and an Email listener which will send out an email whenever an alert is received. Of course, the messages are fully configurable. Numeric Attribute Monitors The first type of monitor is a org.jboss.monitor.ThresholdMonitor that is used to track Numberic MBean attributes. Here is an example configuration of a monitor of free available memory. It will send a JMX Notification when free memory goes below one megabyte. The MBean it is watching over that has this particular stat is jboss.system:type=ServerInfo. File: FreeMemory_Monitor-service.xml FreeMemory Monitor name="ObservedObject">jboss.system:type=ServerInfo FreeMemory 100 1 1000 true jboss.alerts:service=ConsoleAlertListener -list-element> jboss.alerts:service=EmailAlertListener ist-element> Let's walk through each attribute: FreeMemory The display name in which this monitor will be shown in the web-console. If you create monitors by hand you can have it managed by the web-console if you have one monitor defined in one file only and the name of the file is the same name as the monitor and the file lives in ./deploy/management/monitors/ So The above example the filename should be FreeMemory_Monitor-service.xml, notice that whitespace is substituted with an '_' charater. name="ObservedObject">jboss.system:type=ServerInfo FreeMemory These are the MBean and the MBean attribute this monitor will watch. If the MBean is a ServiceMBean then you should make this a so that this monitor doesn't start before the watched MBean is loaded. 100 1 The Threshold is the value threshold of the attribute. The CompareTo is a numeric value, -1 means > (greater than), 0 means = (equal), 1 means (less than). These are the same values used by Java comparators. So in this example, when the FreeMemory attribute is less than 100 a JMX notification will be sent. 1000 The MBean creates a thread that will wake up every so often to check the threshold against the MBean attribute it is watching. The Period is the time in milliseconds this thread will sleep. true Enabled determines whether or not this monitor should actually monitor. It is the on/off switch of the monitor. jboss.alerts:service=ConsoleAlertLis
Re: [JBoss-dev] Remoting and NAT traversal, advanced network
Scott M Stark eloquently wrote the following on 1/6/2004 1:44 PM: The MBeanTracker appears to be a composite of the proxy factory and lookup services currently used and is where the NAT configuration would have to be I would guess. Does this layer support: - A client side interceptor stack - Specifying the class loader used for locating classes on the server side This is what is needed to look to the remoting framework as a replacement for the current proxy factory/detached invoker mechanism. Doesn't have a client side interceptor concept yet - although would be easy to add. I know this is something David Jenks started talking about before and I'm not sure if he did any work in that area. Right now there is some trivial automated class downloading that happens if you make an invocation and the class (either way) doesn't exist - but not well integrated in the UCL and needs to be better thought out. --- 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] [ jboss-Bugs-871649 ] Problem with source of JMX Notifications
OK, good catch. If you extended the Notification object it would fail. I was trying to avoid modifying the real source - but I guess there's no choice. Fix is in. Jeff Adrian Brock wrote: Hi Jeff, You cannot implement it like this: // make a copy of the notification, replacing with the real source of the event Notification n = new Notification(notification.getType(),source,notification.getSequenceNumber(),notification.getTimeStamp(),notification.getMessage()); n.setUserData(notification.getUserData()); return this.delegate.isNotificationEnabled(n); The filter will likely rely upon the type of the Notification which is lost in this implementation. The big problem is that notifications are not required to be clonable, so the only thing you can do is setSource() on the notification with the ObjectName (changing the source for subsequent notification listeners). This is a known issue with the spec. See NotificationListenerProxy. Regards, Adrian On Tue, 2004-01-06 at 14:18, SourceForge.net wrote: Bugs item #871649, was opened at 2004-01-06 08:16 Message generated for change (Comment added) made by jhaynie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=871649&group_id=22866 Category: JBossMX Group: v3.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jeff Haynie (jhaynie) Assigned to: Jeff Haynie (jhaynie) Summary: Problem with source of JMX Notifications Initial Comment: According to the JMX spec, the source of a Notification must be of type ObjectName. At line 420 in ServerImpl: Notification msg = new Notification (START_NOTIFICATION_TYPE, this, 1); should be changed to: Notification msg = new Notification (START_NOTIFICATION_TYPE, ServerImplMBean.OBJECT_NAME, 1); We should also update JMX to check this (although I thought it did before - maybe its happening at the at a higher level in the BasicMBeanRegistry). The problem is that the ListenerRegistration in the NotificationBroadcasterSupport.sendNotification() will evaluate the NotificationFilter before being dispatched up to the listener. The listener is being wrapped at a higher level by the mbean server using the NotificationListenerProxy which sets the source - but this happens after the filter is applied -- which causes problems if you're checking the ObjectName in the filter. An easy enough fix for this particular problem is just to do above. However, I'm worried we'll still see this in other places. Another thought is to wrap the MBeanServerListenerRegistration (which creates NotificationListenerProxy) and pass in a proxy to the filter, such that it will set the appropriate source using the MBeanServerListenerRegistration and then delegate to the appropriate filter. The other thing is to enforce in our Notification implementation ObjectName in setSource and the constructor -- which according to the JMX spec we're suppose to throw an IllegalArgumentException. ------ Comment By: Jeff Haynie (jhaynie) Date: 2004-01-06 09:18 Message: Logged In: YES user_id=4529 This is implemented in 3.2 branch. -- Comment By: Adrian Brock (ejort) Date: 2004-01-06 08:50 Message: Logged In: YES user_id=9459 Yes, go ahead. Regards, Adrian ------ Comment By: Jeff Haynie (jhaynie) Date: 2004-01-06 08:44 Message: Logged In: YES user_id=4529 OK, looking at the JMX 1.2 spec javadoc for Notification, it states: "The Notification class represents a notification emitted by an MBean. It contains a reference to the source MBean: if the notification has been forwarded through the MBean server, this is the object name of the MBean. If the listener has registered directly with the MBean, this is either the object name or a direct reference to the MBean. It is strongly recommended that notification senders use the object name rather than a reference to the MBean object as the source." In my case, and in the case for jboss mx, we're not registering directly with the mbean. I like the idea of filter proxy since it would enforce the ObjectName externally and still allow either ObjectName or direct reference in the implementation of an MBean. Is this something you would like me to apply? -- Comment By: Adrian Brock (ejort) Date: 2004-01-06 08:34 Message: Logged In: YES user_id=9459 The only requirement from the spec is that notification listeners registered through the MBeanServer receive notifications with the ObjectName they registered against. Direct notifications (i.e. where you register directly with the MBean) are not required to use the ObjectName, but direct notifications are frowned upon. You can
[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
dynami
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
[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] Remoting and JMX Remoting Fixes
I've commited a handful of fixes/improvements to remoting and jmx-remoting I've found during testing and profiling our application related to memory growth and dangling threads. - I've added a slight improvement to the multicast detector for caching the detection notification and serialization bytes and only re-serialization if the detection data is different. - the notification cache has an improvement where it will only make one connection to a remote server for async notifications in the event multiple listeners are added. - I added a meaninful name to each thread pool worker thread in the JMX ThreadPool utility class to make it easy during a thread dump to tell what the thread is - I fixed a couple of problems found when doing failure testing of multiple server/clients. - Replaced the NetworkRegistry notifications to use a thread pool vs. creating new threads - I added a listener for detection of remote server failure and destroy the local client proxy to the remote mbean server automatically upon failure. These fixes have been committed to the 3.2 branch. Talking with Tom, he suggested (which I agree) that we wait until we have an official next release before committing these changes to HEAD. I plan to continue running JProbe against both remoting and jmx-remoting in the next week as we continue to integrate the 3.2.4 release into our product and hope to work with Tom to add some more scalability improvements soon. I'm particular interesting in continue to evolve/improve the async transport since I think it has a lot of performance optimizations in cases where a response isn't needed. Jeff --- 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] JMX 1.2, remoting, and jmx-remoting commited to 3.2 branch
OK, I commited this -- remoting services are now deployed in remoting-service.xml in default and all. It's not in minimal. Jeff Scott M Stark wrote: I don't want the remoting code in the conf/jboss-service.xml file yet. This needs to contain only the required services. The remoting services need to be a seperate sar in deploy for easy removal if they are not wanted. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Haynie Sent: Saturday, January 03, 2004 7:45 AM To: [EMAIL PROTECTED] Cc: Tom Elrod Subject: Re: [JBoss-dev] JMX 1.2, remoting, and jmx-remoting commited to 3.2 branch Tom/Scott, The modules remoting and jmx-remoting weren't integrated into the main build and weren't being built into the main distribution. I fixed this and also setup the default detector/connectors to be automatically deployed as part of the default jboss-service.xml. I've committed this fix to the branch. Jeff --- 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 --- 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] JMX 1.2, remoting, and jmx-remoting commited to 3.2 branch
OK, easy enough - that's the way I had it originally. I'll deploy the service.xml instead and commit that. Jeff Scott M Stark wrote: I don't want the remoting code in the conf/jboss-service.xml file yet. This needs to contain only the required services. The remoting services need to be a seperate sar in deploy for easy removal if they are not wanted. Scott Stark Chief Technology Officer JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Haynie Sent: Saturday, January 03, 2004 7:45 AM To: [EMAIL PROTECTED] Cc: Tom Elrod Subject: Re: [JBoss-dev] JMX 1.2, remoting, and jmx-remoting commited to 3.2 branch Tom/Scott, The modules remoting and jmx-remoting weren't integrated into the main build and weren't being built into the main distribution. I fixed this and also setup the default detector/connectors to be automatically deployed as part of the default jboss-service.xml. I've committed this fix to the branch. Jeff --- 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 --- 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] JMX 1.2, remoting, and jmx-remoting commited to 3.2 branch
Tom/Scott, The modules remoting and jmx-remoting weren't integrated into the main build and weren't being built into the main distribution. I fixed this and also setup the default detector/connectors to be automatically deployed as part of the default jboss-service.xml. I've committed this fix to the branch. Jeff Tom Elrod wrote: Just finished backporting JMX 1.2, jboss remoting, and jboss jmx remoting to the 3.2 branch. This puts the 3.2 branch at basically the same code that is at HEAD in regards to the jboss-mx, jboss-remoting, and jboss-jmx-remoting modules. The tag before the commit is 'before_JMX_1_2_checkin' and after commit is 'after_JMX_1_2_checkin'. There are still a few testsuite testcases that are still failing and will be working on fixing them over the next couple of days (mostly related to using dom4j now instead of jdom within jmx, which affects deployment in some cases). There are a lot of test failing now compared to a few days back, but think many are not related to my commit (such as the web services, which were failing before commit). If you find something that does not work that you think is due to this commit, please let me know. Now for the details... These changes will affect the 'jboss-3.2' module, 'Branch_3_2' branch. - Added dom4j.jar to the thirdparty lib and libraries.ent - Updated ManagementBean to support new methods within MBeanServer interface. - Added org.jboss.mx.util.InstanceOfQueryExp back into 3.2 Branch (was not part of original port). - Added dom4j.jar to the system/src/main/org/jboss/Main.java jmxLibs attribute so would be included in the output when doing build. - Updated files in testsuite (mainly import corrections): JNDIPersistence JNDISecurity PrincipalInterceptor ProxyFactoryInterceptor SRPCacheInterceptor OnTimerPersistenceTestCase PrincipalInterceptor SecurityInterceptor NBMBeanTestCase.java Updated XMBean to accept both w3c and dom4j Element as parameter to constructor. This allows to be compatible with older code (using w3c) and new code (where XMLMetaData requires dom4j Element). Removed: jmx\src\main\org\jboss\mx\interceptor\Invocation.java jmx\src\main\org\jboss\mx\interceptor\InvocationException.java jmx\src\main\org\jboss\mx\interceptor\MBeanAttributeInterceptor.java jmx\src\main\org\jboss\mx\interceptor\ModelMBeanInterceptor.java jmx\src\main\org\jboss\mx\interceptor\ObjectReferenceInterceptor.java jmx\src\main\org\jboss\mx\interceptor\PersistenceInterceptor2.java jmx\src\main\org\jboss\mx\interceptor\StandardMBeanInterceptor.java jmx\src\main\org\jboss\mx\server\StandardMBeanInvoker.java And, of course, hundreds of files updated within jboss-mx module, as well as adding jboss-remoting and jboss-jmx-remoting modules. --- 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] [ jboss-Feature Requests-858049 ] JBoss HTTP Signature
It would be nice to be configurable as well. I.E. Apache Coyote/1.0 JBoss/3.2.3 OEM/ISV/1.0 Jeff - Original Message - From: "SourceForge.net" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 10, 2003 11:31 PM Subject: [JBoss-dev] [ jboss-Feature Requests-858049 ] JBoss HTTP Signature > Feature Requests item #858049, was opened at 2003-12-11 04:31 > Message generated for change (Tracker Item Submitted) made by Item Submitter > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=376688&aid=858049&group_id=22866 > > Category: None > Group: None > Status: Open > Resolution: None > Priority: 5 > Submitted By: Ivelin Atanasoff Ivanov (ivelin) > Assigned to: Nobody/Anonymous (nobody) > Summary: JBoss HTTP Signature > > Initial Comment: > The HTTP Response signature should be modified, so that > statistics collection spiders can count JBoss deployments. > This is important to be able to track objectively the > JBoss market growth. > > Companies like Netcraft and E-Soft publish periodical > statistics about the market penetration of certain > server side technologies. > PHP use it successfully as a marketing tool. > http://www.securityspace.com/s_survey/data/man.200311/apachemods.html > > The current JBoss signature is: > Apache Coyote/1.0 > > It should be something like: > Apache Coyote/1.0 JBoss/3.2.3 > > For comparison the PHP signature is: > Apache/1.3.26 (Unix) mod_gzip/1.3.26.1a PHP/4.3.3-dev > > > Ivelin > > > -- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=376688&aid=858049&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 --- 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] several ThreadPool classes
I thought we were using the doug lea's concurrent ThreadPool (PooledExecutor) in most places? - Original Message - From: "Tom Elrod" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 01, 2003 2:04 AM Subject: [JBoss-dev] several ThreadPool classes > I need a thread pool and upon checking, noticed that we have several > implementations through out. However none were in common (and two of > them look exactly the same). Any one in particular that should be > considered the "standard" thread pool? If so, any reason it is not in > common? > > Thanks. > > -Tom > > > > --- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: [jboss-group] JRMPInvokerProxy
Nice to see Marc is still on the "remoting is tied to JMX kick" which is completely and utterally incorrect. ;) Remoting has nothing to do with JMX, except that as a convenience the connectors serve as MBeans. - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, September 20, 2003 11:22 AM Subject: RE: [JBoss-dev] Re: [jboss-group] JRMPInvokerProxy > > - Generalization of the proxy factory framework to loose the > > ejb specific items > > manifestly showing up in the > > org.jboss.proxy.GenericProxyFactory which should be > > a more generic metadata representation. The only difference > > between the http > > proxy factory and jrmp proxy factory is a different Invoker > > type and the lack of > > a jndi name. > > Great > > > - The whole Invoker layer needs to be migrated to the more > > general remoting > > framework. The remoting > > Ok, I am unfamiliar with that framework. The only 'surface' problem I > would have would be to tie it to JMX. The targets need to be identified > by logical names. The logical names are mapped to 'handlers', for > example a JMX one that understands the target identifier as a JMX > MBeanName etc. > > > - There is an XMBean interceptor which implements the > > invoke(Invocation) > > handling in the 3.2.1 admin/devel book which should be rolled > > into the codebase. > > The problem here is that is has to deal with 2 types of > > Invocations and two type > > of Interceptors. This needs to be unified. > > Unifying the interceptors would be a good idea. The only thing that > needs to be "multiple" is AOP that deals with interfaces (Dynamic Proxy) > or the AOP that deals with raw objects and the javassist framework. But > definitely the SIGNATURE of the invocation should be unified so that > interceptors themselves come in ONE flavor > > Public Invocation invoke(Invocation) > > And then we can weave these in the EJB contaienr, the XMBean container > (the first two should be unified in their constructions as well as you > point out) and raw AOP containers with assembly based on the XML bill > has. But all the interceptors should have the same API, same thing with > the Invocation object itself, good call on that. > > Marcf > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > JBoss-Development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ManagementBean and RemoteMbeanServer
JSR160 is partially implemented in HEAD and talks to Jboss Remoting API. It shouldn't be too much longer to have a full implementation working. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luke Taylor Sent: Tuesday, June 17, 2003 2:44 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ManagementBean and RemoteMbeanServer Luke Taylor wrote: > Adrian Brock wrote: > >> Hi Luke, >> >> In head, the plan is to use jsr160 and >> the MBeanServerConnection interface >> from jmx1.2 >> > OK, thanks Adrian. I'll have a look at that. > I've used an MBeanServer instance for the time being 'cos that compiles OK and I'm not sure exactly what the future plans are. Otherwise I'd have to put in lots of catch blocks for IOExceptions which the connection interface throws. Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.monkeymachine.ltd.uk --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss remoting callbacks [was JB4DR1 Deadline MAY 26]
I think Bill and I need to come up with a generic enough AOP remoting with callbacks (which we have a start of) and provide that as part of the Invocation to interceptors so that the J2EE services can just use that w/o having to know anything about the remoting parts. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Phelps Sent: Friday, April 04, 2003 10:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss remoting callbacks [was JB4DR1 Deadline MAY 26] I question if A JMSServerInvocationHandler is even necessary (along with the JMS Subsystem) if Bill exposes the callbacks via the AOP remoting framework. Frankly, I have the same thought about all the "subsystems" as I know EJB for instance will also being using the AOP framework and therefore the AOPServerInvocationHandler. I know you guys have a JMX subsystem which you have used to implement JMX remoting, but if you decide to refactor that to use the AOP framework that subsystem wouldn't be necessary either as far as I understand it. What I'm getting at is that it is my understanding that the future of J2EE flavored services on JBoss will be built on top of the AOP framework, and therefore AOP remoting is going to be the only InvocationHandler used because it is what gives us the modern interceptor stack. Bill, am I correct? Thanks, Nathan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Friday, April 04, 2003 1:05 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss remoting callbacks [was JB4DR1 Deadline MAY 26] Guess Jeff beat me to it ;) > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Tom > Elrod > Sent: Friday, April 04, 2003 1:49 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JBoss remoting callbacks [was JB4DR1 Deadline > MAY 26] > > > Jeff made the fix last night and I have not looked at the > code yet (he still > has it local while we are testing that and some other fixes > out). However, > my understanding from Jeff is that the invoker client passes > its locator to > the invoker server if it wishes to receive callbacks. The > invoker server > will then use that for establishing the connection back to > the client to > send notifications (callbacks). > > Given this, it will be pretty easy to make it so the calling > code can give > the client invoker the locator to use for callbacks, which it > then gives the > invoker server (and will use its own by default as is now). > I can put this > in this weekend (if Jeff doesn't beat me to it). > > It sounds like there won't be enough time to include JMS as one of the > invoker transport before the deadline. However, I would personally be > interested in working with you on it. Depending on how soon you will > have time to start on it, might be wise to make a branch just for the > JMS transport, until JB4DR1. > > -Tom > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > > Nathan Phelps > > Sent: Thursday, April 03, 2003 11:44 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > > > > Did you guys end up doing it in such a way so that you can use one > > protocol one way and another protocol the other way like you had > > mentioned? > > > > Secondly, what is really going to be cool when we expose > this via AOP > > remoting... Bill, what are your plans for that? > > > > Thanks, > > > > Nathan > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Jeff Haynie > > Sent: Thursday, April 03, 2003 8:21 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > > Jboss Remoting callbacks are in - I wil commit in the next day or so > > when tom and I finish testing. > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Bill Burke > > Sent: Thursday, April 03, 2003 6:06 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > > > > I'm ok with JMS. I didn't think you could rewrite in such short of > > time. Especially with Remoting and AOP just now becoming stable. I > > think this email thread is good because it will allow us to > determine > > whether or not we can release. I still think there is enough > > functionality. > > > > Bill > > > > > -Original Message--
RE: [JBoss-dev] JB4DR1 Deadline MAY 26
We haven't added the different protocols, but that should be easy enough to do and a great idea. I sent bill a note tonight about doing a generic AOP remoting event/listener framework for POJOs. My thought is using generic JavaBean style java.util.EventListener/java.util.EventObject (or bounded properties, etc) so you could dynamically attach remote listeners to regular POJOs to get remote events. Nathan, do you want me to help you with doing a JMSServerInvocationHandler? -- I would like to refactor down the async event stuff in JMX into the base remoting framework so that you just deal with the functionality pieces of listeners/events in the invocation handler. I really need another good subsystem to make sure it gets refactored properly. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Phelps Sent: Thursday, April 03, 2003 11:44 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 Did you guys end up doing it in such a way so that you can use one protocol one way and another protocol the other way like you had mentioned? Secondly, what is really going to be cool when we expose this via AOP remoting... Bill, what are your plans for that? Thanks, Nathan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Haynie Sent: Thursday, April 03, 2003 8:21 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 Jboss Remoting callbacks are in - I wil commit in the next day or so when tom and I finish testing. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Thursday, April 03, 2003 6:06 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 I'm ok with JMS. I didn't think you could rewrite in such short of time. Especially with Remoting and AOP just now becoming stable. I think this email thread is good because it will allow us to determine whether or not we can release. I still think there is enough functionality. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Nathan Phelps > Sent: Thursday, April 03, 2003 5:48 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > > I agree that there is some great stuff in there already. However, > being that the AOP transaction, security, remoting, etc. was only > recently released in its first iteration, and the fact that JBoss > remoting doesn't yet support true callbacks (Jeff says it is coming) > there is simply no way I can deliver the new JMS implementation BUILT > ON TOP of these services by May 5th! And I'm going to be out > basically two weeks between now and then with customers as I know > others will be as well. > > Since the whole point of the JMS rewrite is to take advantage of the > core JBoss AOP services, I haven't really had that much time to do so > since the services have only recently been released. Therefore, I > expect that a May 26th release will ONLY INCLUDE THE OLD JMS CODE > which is currently in HEAD. It is the only option with a May 5th > deadline in my opinion. If everyone is OK with this and we're > committed to that date, then I am must immediately shift my attention > from the development of the new code build on top of the AOP framework > to the old code currently in HEAD to start working on ensuring JMS 1.1 > compliance, stability, etc. as well as applying the HTTP IL code currently only in > Branch_3_2 to HEAD. Then, after the May 26th release, I'll continue > working on the new JMS code which is build on top of the AOP > framework. > > Comments? > > Thanks, > > Nathan > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Bill Burke > Sent: Thursday, April 03, 2003 3:22 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 > > There's already a lot we can release. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > Dain > > Sundstrom > > Sent: Thursday, April 03, 2003 4:01 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > > > > I think you are delusional if you think JB4 will be ready for > > JavaOne. > > > > -dain > > > > On Thursday, April 3, 2003, at 02:47 PM, marc fleury wrote: > > > > > Guys, > > > > > > We are thinking a lot about the forthcoming JB4 release. It is a > truly > > > exciting step for us as we believe we will bring a programming > style, > > > whose time has come, to a mass audience. > > > >
RE: [JBoss-dev] JB4DR1 Deadline MAY 26
Jboss Remoting callbacks are in - I wil commit in the next day or so when tom and I finish testing. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Thursday, April 03, 2003 6:06 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 I'm ok with JMS. I didn't think you could rewrite in such short of time. Especially with Remoting and AOP just now becoming stable. I think this email thread is good because it will allow us to determine whether or not we can release. I still think there is enough functionality. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Nathan Phelps > Sent: Thursday, April 03, 2003 5:48 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > > I agree that there is some great stuff in there already. However, > being that the AOP transaction, security, remoting, etc. was only > recently released in its first iteration, and the fact that JBoss > remoting doesn't yet support true callbacks (Jeff says it is coming) > there is simply no way I can deliver the new JMS implementation BUILT > ON TOP of these services by May 5th! And I'm going to be out > basically two weeks between now and then with customers as I know > others will be as well. > > Since the whole point of the JMS rewrite is to take advantage of the > core JBoss AOP services, I haven't really had that much time to do so > since the services have only recently been released. Therefore, I > expect that a May 26th release will ONLY INCLUDE THE OLD JMS CODE > which is currently in HEAD. It is the only option with a May 5th > deadline in my opinion. If everyone is OK with this and we're > committed to that date, then I am must immediately shift my attention > from the development of the new code build on top of the AOP framework > to the old code currently in HEAD to start working on ensuring JMS 1.1 > compliance, stability, etc. as well as applying the HTTP IL code currently only in > Branch_3_2 to HEAD. Then, after the May 26th release, I'll continue > working on the new JMS code which is build on top of the AOP > framework. > > Comments? > > Thanks, > > Nathan > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Bill Burke > Sent: Thursday, April 03, 2003 3:22 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 > > There's already a lot we can release. > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > Dain > > Sundstrom > > Sent: Thursday, April 03, 2003 4:01 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 > > > > > > I think you are delusional if you think JB4 will be ready for > > JavaOne. > > > > -dain > > > > On Thursday, April 3, 2003, at 02:47 PM, marc fleury wrote: > > > > > Guys, > > > > > > We are thinking a lot about the forthcoming JB4 release. It is a > truly > > > exciting step for us as we believe we will bring a programming > style, > > > whose time has come, to a mass audience. > > > > > > AOP as Bill says is a clear wave for system level services on par > with > > > OOP. On top of it and also as a proof of how powerful the > > > approach > is > > > we still develop a full J2EE server. Meaning that you can choose > > > to live in the J2EE world work on JBoss J2EE and access all the > > > prepackaged AOP goodies as you have been doing since JBoss2.0. > > > > > > There seems to be a lot of fear at SUN from what I can tell in the > > > press, that we will abandon J2EE. We love J2EE. When really we > > > will support J2EE for the forthcoming future. Never do we talk > > > about "abandoning" J2EE, we just let the user access core > > > functionality in > > > > the > > > open server and think at the AOP level. A more fundamental > construct > > > of > > > the framework. > > > > > > The reason we are almost there is that it is also a very old > > > implementation in JBoss. We have been doing it for a long time > > > but never talked/packaged it this way. We make it easy for you to > leverage > > > the AOP layer. The implementation is old the way you interact with > > > JBoss is new. It can also be old if you decide to stay at the > > > J2EE level which will be fully supported. > > > > > > But you are now invited to roam in the core JBoss system, in fact > you > > > may find it very cozy as you port POJO based applications to > > > JBoss. There will be a stabilization period though. We are making > > > an aggressive push to release JB4 by JavaONE with all our > > > resources dedicated to implementing the final AOP system aspects > > > and porting > some > > > of the existing code to that. > > > > > > We're making an aggressive push to release JBoss 4.0 by JavaOne. > We're > > > targeting May 26th. That leaves us 2 month from now. > > > > > > I REPEAT TARG
RE: [JBoss-dev] Regarding JBoss site
On IE6.0 on W2K, the drop downs on the front page, such as Forums...Development, doesn't do anything. However, if I click on Forums... It goes to the main forums page. Also, when I try and login, I get a "Logging you in, hang tight!" and the page never returns The IE globe spins to infinity -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of marc fleury Sent: Thursday, March 27, 2003 11:36 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Regarding JBoss site you are saying get rid of the ads? that is not going to be possible right now :) if it is something more precise let me know marcf > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Juha-P Lindfors > Sent: Thursday, March 27, 2003 11:24 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Regarding JBoss site > > > > It's not the new look that is bad (the red bar and the menu) > its all the other stuff that blinks worse than your average > porn site. An eyesore. Too much stuff that just bounces around. > > Looks is good, should continue to apply it to the rest of the > stuff. Layout is bad, needs a complete redesign (mostly ads). > > -- Juha > > On Thu, 27 Mar 2003, marc fleury wrote: > > > Points taken on the website. > > > > Do you prefer the look though? we are trying the more "pro" > approach. > > I think it sucks but ben my sales guy is all excited about > it... what > > do you think? we just released NUKES, the forums were switched and > > yes we lost a couple of hours of posts. Apologies and thanks for > > sending us broken links and stuff. > > > > As for the TSS "hate" it is not hate, it is simple > jealousy. We said > > for the first time that we make money and that we share it. > > > > Put yourself in the shoes of the mediocrity that usually > reads/writes > > there and he used to sit smug thinking about how DUMB we > are because > > we do open source and we probably BEG for money and all of > the sudden > > BM we make money while he struggles to keep his stupid company > > afloat. > > > > Jealousy is a deep reptilian feeling that in fact takes precedence > > over common sense. It is a fact of life. The more success > we have the > > more we are going to see of that, I mean think MS the biggest and > > baddest of them all attracts even more jealousy. > > > > Meaning: let them be jealous and lets stay the course, we > will start > > receiving resumes from these mediocrities that never wrote > a line of > > OSS code in the coming weeks, > > > > stay the course > > > > marcf > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On > Behalf Of > > > Lennart Petersson > > > Sent: Thursday, March 27, 2003 10:29 AM > > > To: [EMAIL PROTECTED] > > > Subject: [JBoss-dev] Regarding JBoss site > > > > > > > > > Please would it possible to have JBoss site > stabilised? As it is > > > now you never know what it will be like next time surfing > there > > > and forum messages that i sent yesterday is now suddenly gone and > > > other threads reports to be updated but they arent > And are there > > > really 620 guests on-line :) > > > > > > I know there is development going on but does it have to > affect the > > > production site? Especially since there is a lot of JBoss > hate going > > > on (look at TSS if you haven't yet) I think there will be a lot of > > > curious people coming surfing and this is not what I want them to > > > see... > > > > > > /L > > > > > > > > > > > > --- > > > This SF.net email is sponsored by: > > > The Definitive IT and Networking Event. Be There! > > > NetWorld+Interop Las Vegas 2003 -- Register today! > > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > --- > > This SF.net email is sponsored by: > > The Definitive IT and Networking Event. Be There! > > NetWorld+Interop Las Vegas 2003 -- Register today! > > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > > ___ > > Jboss-development mailing list > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > -- > Juha Lindfors > Author of "JMX: Managing J2EE with Java Management Extensions" > > > > > --- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > ___ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/list
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
>I'm not sure...The problem with Versioning and Remoting is that a proxy object is required. You have to return a different object than the one actually constructed. >You getting me? I'm not sure if this can be done within bytecode manipulation. I'll have to ask the Javassist guys. Why? Basically in rmeoting, you would just dispatch each method invocation across the wire and the local object would just serve as a phantom object and not actually contain any state, etc. Why does it has to be a real proxy...? Maybe I'm not following. That way, I could new an object, which is actually a local representation of a remoted object on another machine. I could also add a clustered intercetor which might then load balance invocations across to different real remote objects. I think this is possible. Right? Another thing to think about ... After looking at the javassist docs last night is something like using casting to dynamically add interceptors. This might be bad, haven't thought through all the implications ... But, imagine: Foo foo = new Foo (); // local object ((Transactable)foo).beginTx(); Foo.bar(); ((Transactable)foo).commitTx(); What if the mere casting of an object would allow you to dynamically attach an interceptor to the object before the invocation? This might be fairly powerful too. Looking at the javassist docs, it looks like you can get called on a Cast and InstanceOf call to an object. Maybe I'm being too whacky here ... Not sure. Something to ponder. Jeff --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
>JBoss Remoting is much more fabulous. We need to get the word out on it... I need to write some darn docs.. Too busy trying to get a new release out on our side. Not enough hours in a day. > I totally agree. And yes, a constructor pointcut is the way to go. The only downside of constructor pointcuts is that reflection bypasses the interception! > Same thing with field interception. The problem is that unlike methods, you have to modify the bytecode of the calling logic. Could you dynamically do an insertBefore into the CtConstructor of the advised class which would do the interception, even on reflection? > I will write some testcases that put the whole stack together with constructor pointcuts. > > I'm also working on the concept of an abstract Container. But you got me thinking that constructor pointcuts may be enough... I was just going to email you about the Container - just looking through the code. Is this just the ability to create an AOP namespace or something? --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] AOP versioned ACID objects 1st iteration
Bill, This is fabulous stuff. Good job. Is there a way we might be able to use the AOP xml to dynamically do your example below (as well as the clustered and remoting) for POJOs during construction time? In other words, could you not have an interceptor on a constructor pointcut that would do this for you and dynamically make the class Versionable, Clusterable, Remotable, etc. so that the actual instance you receive back has these capabilities transparently w/o having to programatically do this? The advantages of this would be that you could dynamically modify the POJO from the XML file without having to do it programmatically (of course, you could if you wanted to). That way, we can truly separate the business logic (as an example, no flames here) from the cross-cutting of concerns such as transactibility, security, remoteness, etc. Looking at the jboss-aop.xml in the testsuite - it looks like you're doing this with the Tx Interceptor on the VersionedPOJO - why not just create the VersionedPOJO in the same way and insert the Versioned Interceptor the same way? Is this possible? Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Wednesday, March 26, 2003 7:09 PM To: Jboss-Dev Subject: [JBoss-dev] AOP versioned ACID objects 1st iteration I have implemented a new AOP service for Serializable POJOs, Versioned Objects. You can transactionally version an object. If you modify the object within a transaction, this modification is not seen by other transactions. If the tx commits, the changes seen, if a rollback happens the changes are rolled back. On commit, if another tx has modified the object, the tx will rollback (OptimisticLocking). The way it works is as follows: POJO pojo = new POJO(); pojo = (POJO)org.jboss.aop.plugins.Versioned.makeVersioned(pojo); calling Versioned.makeVersioned creates a proxy that sits in front of the real object. transactionManager.begin(); pojo.callMethod(); when callMethod is invoked since there is a transaction, an interceptor creates a copy of the REAL pojo and does all further invocations on this copy. pojo.someField = 5; If you have field interception turned on, public field will also be accessed via the copy/version tm.commit(); On commit, a tx Synchronization checks to see if the version you have created is the latest and greatest. If not an org.jboss.aop.plugins.OptimisticLockFailure exception is thrown in beforeCompletion. I'm not sure how this exception is wrapped. Some other semantics: 1. All method invocations force a version to be created. You can avoid this by declared class-metadata as follows: true A readonly method will not cause the creation of a version and the current object will be used. An example and unit test is under testsuite/src/main/org/jboss/test/aop/bean/VersionedObjectTester.java The example object VersionedPOJO.java, has 1 interceptor pointcut declared on the class to do Tx stuff. See testsuite/src/resources/aop/META-INF/jboss-aop.xml for more details. What would be nice is to also write a TransactionalLock interceptor for versioned POJO's that have high OptimisticLock failures. Bill --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jboss/David Vs. Sun/Goliath?
Famous quote from Sun on News.com: http://news.com.com/2100-1013-993471.html?tag=fd_top 'Phipps said Wednesday that making the compliance test available will make it clear that Sun does not want to intentionally obstruct JBoss Group's efforts to gain J2EE compliance. However, Phipps said he doubts that JBoss software will pass the compliance test. Basing his opinion on public information, he said, JBoss software does not appear to implement all of the J2EE specification. "I predict that now that we're calling their bluff, they will make up another excuse for not doing the tests," Phipps said. ' So, Sun's calling our bluff??? --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] AOP Clustering 1st iteration
You're on fire! Go go Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill
Burke
Sent: Tuesday, March 18, 2003 7:15 PM
To: Jboss-Dev
Subject: [JBoss-dev] AOP Clustering 1st iteration
Again, either an AOP instrumented or non-AOP instrumented pojo can be
remotely clustered.
An example is in
testsuite/src/main/org/jboss/test/aop/bean/RemotingTester.java
config is in testsuite/src/resource/aop/jboss-service.xml
POJO pojo = new POJO("hello");
String objectId = "clusteredObj";
POJO proxy = (POJO)ClusteredRemoting.registerClusteredObject(objectId,
pojo,
"DefaultPartition", new RoundRobin(),
new
InvokerLocator("socket://xeon:5150"));
That's it
More doco later,
Bill Burke
Chief Architect
JBoss Group, LLC
---
This SF.net email is sponsored by: Does your code think in ink?
You could win a Tablet PC. Get a free Tablet PC hat just for playing.
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Jboss-development mailing list [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by: Does your code think in ink?
You could win a Tablet PC. Get a free Tablet PC hat just for playing.
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: Re[2]: [JBoss-dev] JBoss-3.2 build issues
Compression level on the cvs server -z9 is the max -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Phelps Sent: Tuesday, March 18, 2003 12:19 PM To: [EMAIL PROTECTED] Subject: RE: Re[2]: [JBoss-dev] JBoss-3.2 build issues I've never been able to find documentation for what the -z3 switch does. What is it for? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Tuesday, March 18, 2003 10:37 AM To: [EMAIL PROTECTED] Subject: Re: Re[2]: [JBoss-dev] JBoss-3.2 build issues You have to specify the branch as well. I don't know how you ever could have gotten this to compile either. Use cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/jboss co -r Branch_3_2 jboss-3.2 Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Alex Loubyansky" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]> Sent: Tuesday, March 18, 2003 7:22 AM Subject: Re[2]: [JBoss-dev] JBoss-3.2 build issues > Amazing... I wonder how it got mixed. > I should have used > cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/jboss co jboss-3.2 > > Is it correct? Should I specify branch version in addition? I never did > it and had no problems. > > Thank you, > alex --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Naming a core module?
There's a difference between build-time dependencies and run-time dependencies. To build the SOAP connector, it requires Axis to build remoting. However, during execution, if you don't have Axis on your classpath, it won't be available, and won't cause a run-time dependencies. The intent is to only have a minimal amount of support that is part of the core JDK - such as Sockets, RMI, IIOP for Connectors and multicast, JNDI for Detectors. If different protocols are desired beyond that and we support them, you can just add the dependent JARs and they become available. I think this is what you want ... However, with the build, it is sometimes harder (at least for the non-expert buildmagic humans) to figure out how to link in other modules (for build only) such as the naming stuff, just for compiling the code. If there is a better way, can someone help us out here? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Sunday, March 09, 2003 11:16 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Naming a core module? The only protocols that can be included in the core are those natively supported by the VM. I certainly do not want to force these all of these extra protocol dependencies down into the core just because they might be used to access JMX. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Tom Elrod" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, March 08, 2003 11:02 PM Subject: RE: [JBoss-dev] Naming a core module? > I agree that it doesn't make sense to have naming in core. Actually > noted this in the e-mail I sent out when I made the commit. > > However, don't have a solution off-hand for how we can include modules > and jars in remoting (and yet exclude the from core, without removing > remoting, which jmx now depends on). This will probably become more > of problem as the list of these such things continues to grow, since > more and more protocols (JMS, IIOP, etc.) and detectors (JINI, SLP, > etc.) will be added over time. Already includes SOAP and JNDI, which > really don't belong in core. > > Best suggestion I can give is to remove remoting from core, create yet > another sub module for jmx remoting which will depend on remoting and > jmx (thus leaving jmx in core without needing remoting). As you can > see, this makes things much more complex in regards to development, > building, and deploying (which is pretty complex to begin with). Just > have to weigh the trade-offs. > > Whatever the preference, I will be on vacation next week so won't be > able to do anything with it till I get back. > > -Tom --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Naming a core module?
Tom did this the other day when he integrated the JNDI detector into remoting, but just for source build dependencies only. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Saturday, March 08, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Naming a core module? When did naming become a core module? Appears that a remoting test depends upon it. Is this what we really want? The core is now dependent on naming to build... naming is a service, not part of the core system. Any way we can fix this so the dependencies are not whack? --jason --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
No, this just allows remote jboss servers to be discovered by browsing the JNDI tree instead of multicast. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Jencks Sent: Saturday, March 08, 2003 7:59 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed Does this change prevent us from writing a remote jndi implementation that runs over the remoting framework? If so, is this the direction we want to go in? david jencks On 2003.03.07 03:10 Tom Elrod wrote: > Build fixed now. Please note that naming is now part of core modules. > This > is due to remoting now requiring naming, since the addition of a JNDI > detector. > > -Tom > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > > Tom Elrod > > Sent: Friday, March 07, 2003 2:55 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed > > > > > > I did this while in process of doing checkin. Should be fixed in a > > minute. > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Behalf Of > > > [EMAIL PROTECTED] > > > Sent: Friday, March 07, 2003 2:34 AM > > > To: [EMAIL PROTECTED] > > > Cc: [EMAIL PROTECTED] > > > Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed > > > > > > > > > > > > > > > > = > > > ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR > > > DETAILS= > > > > > > > = > > > > > > JAVA VERSION DETAILS > > > java version "1.3.1_06" > > > Java(TM) 2 Runtime Environment, Standard Edition (build > > 1.3.1_06-b01) > > > Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) > > > > > > > > > > = > > > > > > HERE ARE THE LAST 50 LINES OF THE LOG FILE > > > > > > [mkdir] Created dir: > > > /home/jboss/jbossci/jboss-head/remoting/output/classes > > > [mkdir] Created dir: > > > /home/jboss/jbossci/jboss-head/remoting/output/gen/classes > > >[depend] Deleted 0 out of date files in 0 seconds > > > [javac] Compiling 62 source files to > > > /home/jboss/jbossci/jboss-head/remoting/output/classes > > > /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem > > oting/detection/jndi/JNDIDetector.java:19: cannot resolve symbol > > > symbol : class NamingContextFactory > > > location: package interfaces > > > import org.jnp.interfaces.NamingContextFactory; > > > ^ > > > /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem > > oting/detection/jndi/JNDIDetector.java:20: cannot resolve symbol > > > symbol : class Main > > > location: package server > > > import org.jnp.server.Main; > > > ^ > > > /home/jboss/jbossci/jboss-head/remoting/src/main/test/detectio > > n/jndi/JNDIDetectorTest.java:15: cannot resolve symbol > > > symbol : class Main > > > location: package server > > > import org.jnp.server.Main; > > > ^ > > > /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem > > oting/detection/jndi/JNDIDetector.java:365: cannot resolve symbol > > > symbol : class Main > > > location: class org.jboss.remoting.detection.jndi.JNDIDetector > > > Main server = new Main(); > > > ^ > > > /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem > > oting/detection/jndi/JNDIDetector.java:365: cannot resolve symbol > > > symbol : class Main > > > location: class org.jboss.remoting.detection.jndi.JNDIDetector > > > Main server = new Main(); > > > ^ > > > /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem > > oting/detection/jndi/JNDIDetector.java:370: cannot resolve symbol > > > symbol : class NamingContextFactory > > > location: class org.jboss.remoting.detection.jndi.JNDIDetector > > > contextFactory = > > NamingContextFactory.class.getName(); > > > ^ > > > /home/jboss/jbossci/jboss-head/remoting/src/main/test/detectio > > n/jndi/JNDIDetectorTest.java:57: cannot resolve symbol > > > symbol : class Main > > > location: class test.detection.jndi.JNDIDetectorTest > > > Main JNDIServer = new Main(); > > > ^ > > > /home/jboss/jbossci/jboss-head/remoting/src/main/test/detectio > > n/jndi/JNDIDetectorTest.java:57: cannot resolve symbol > > > symbol : class Main > > > location: class test.detection.jndi.JNDIDetectorTest > > > Main JNDIServer = new Main(); > > > ^ > > > 8 errors > > > > > > BUILD FAILED > > > file:/home/jboss/jbossci/jboss-head/remoting/../tools/etc/buil > > dfragments/targets.ent:45: Compile failed; see the compiler error > > output for details. > > > > T
RE: [JBoss-dev] jboss remoting
I'm working on this ... Should have something sometime soon. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of marc fleury Sent: Friday, March 07, 2003 4:21 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] jboss remoting > I'm not sure if it so much of an issue since only DP classes > will be downloaded. clearly. ALSO PLEASE LET"S PUT SOME DOCUMENTATION IN PLACE. Beginner and advanced, we need to streamline this as communicating on the development is the key, thanks for doing this bill. Again the new website (next week we are done with Nukes and we are putting the content) will help with this as well as some new and long overdue procedures for doco, marcf --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jboss Boot lib jars
Obviously not, since it boots w/o it. ;) It threw me off since it was in lib/ I just expected that to be the case. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Friday, March 07, 2003 5:26 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Jboss Boot lib jars Is jboss-cache required to boot the server? --jason On Saturday, March 8, 2003, at 05:21 AM, Jeff Haynie wrote: > Because bela's jboss-cache is in lib/ on the build, but not configured > in Main. So, I had to chase that down a bit before looking at the > source. > > Thus, I was wondering why not just take everything in lib/* > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jason Dillon > Sent: Friday, March 07, 2003 5:16 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Jboss Boot lib jars > > > I have no exp. with WebDav so I can not say... but do we want to force > the usage of Webdav? I personally do not like to force anything. Why > the concern? > > --jason > > > On Saturday, March 8, 2003, at 05:02 AM, Jeff Haynie wrote: > >> Ok, this makes sense .. >> >> can't we list even if remote using WebDav? >> >> -Original Message- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of >> Jason Dillon >> Sent: Friday, March 07, 2003 4:07 PM >> To: [EMAIL PROTECTED] >> Subject: Re: [JBoss-dev] Jboss Boot lib jars >> >> >> The jars which are hardcoded in Main are references to jars which are >> required to load up the server. We can not assume that those jars >> are > >> on the local file system and thus can not query a directory to >> discover which jars need to be loaded. >> >> If you would rather not have them hardcoded then perhaps an external >> property file would work. We certainly do not want to be bound to >> the > >> file system again. >> >> --jason >> >> >> On Saturday, March 8, 2003, at 03:40 AM, Jeff Haynie wrote: >> >>> Is there any reason we need to hardcode the jars that are included >>> in > >>> the lib directory? (in org.jboss.Main) >>> >>> Can't we just put all the *.jars under /lib into the class >>> loader on boot? >>> >>> >>> Jeff >>> >>> >>> >>> >>> --- >>> This SF.net email is sponsored by: Etnus, makers of TotalView, The >>> debugger for complex code. Debugging C/C++ programs can leave you >>> feeling lost and disoriented. TotalView can help you find your way. >>> Available on major UNIX >>> and Linux platforms. Try it free. www.etnus.com >>> ___ >>> Jboss-development mailing list >>> [EMAIL PROTECTED] >>> https://lists.sourceforge.net/lists/listinfo/jboss-development >>> >> >> >> >> --- >> This SF.net email is sponsored by: Etnus, makers of TotalView, The >> debugger for complex code. Debugging C/C++ programs can leave you >> feeling lost and disoriented. TotalView can help you find your way. >> Available on major UNIX >> and Linux platforms. Try it free. www.etnus.com >> ___ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development >> >> >> >> >> --- >> This SF.net email is sponsored by: Etnus, makers of TotalView, The >> debugger for complex code. Debugging C/C++ programs can leave you >> feeling lost and >> disoriented. TotalView can help you find your way. Available on major >> UNIX >> and Linux platforms. Try it free. www.etnus.com >> ___ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > > > --- > This SF.net email is sponsored by: Etnus, makers of TotalView, The > debugger for complex code. Debugging C/C++ programs can leave you > feeling lost and > disoriented. TotalView can help you find your way. Available on major > UNIX > and Linux platforms. Try it free. www.etnus.com > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lis
RE: [JBoss-dev] Jboss Boot lib jars
Because bela's jboss-cache is in lib/ on the build, but not configured in Main. So, I had to chase that down a bit before looking at the source. Thus, I was wondering why not just take everything in lib/* -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Friday, March 07, 2003 5:16 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Jboss Boot lib jars I have no exp. with WebDav so I can not say... but do we want to force the usage of Webdav? I personally do not like to force anything. Why the concern? --jason On Saturday, March 8, 2003, at 05:02 AM, Jeff Haynie wrote: > Ok, this makes sense .. > > can't we list even if remote using WebDav? > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jason Dillon > Sent: Friday, March 07, 2003 4:07 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Jboss Boot lib jars > > > The jars which are hardcoded in Main are references to jars which are > required to load up the server. We can not assume that those jars are > on the local file system and thus can not query a directory to > discover which jars need to be loaded. > > If you would rather not have them hardcoded then perhaps an external > property file would work. We certainly do not want to be bound to the > file system again. > > --jason > > > On Saturday, March 8, 2003, at 03:40 AM, Jeff Haynie wrote: > >> Is there any reason we need to hardcode the jars that are included in >> the lib directory? (in org.jboss.Main) >> >> Can't we just put all the *.jars under /lib into the class >> loader on boot? >> >> >> Jeff >> >> >> >> >> --- >> This SF.net email is sponsored by: Etnus, makers of TotalView, The >> debugger for complex code. Debugging C/C++ programs can leave you >> feeling lost and >> disoriented. TotalView can help you find your way. Available on major >> UNIX >> and Linux platforms. Try it free. www.etnus.com >> ___ >> Jboss-development mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/jboss-development >> > > > > --- > This SF.net email is sponsored by: Etnus, makers of TotalView, The > debugger for complex code. Debugging C/C++ programs can leave you > feeling lost and > disoriented. TotalView can help you find your way. Available on major > UNIX > and Linux platforms. Try it free. www.etnus.com > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > --- > This SF.net email is sponsored by: Etnus, makers of TotalView, The > debugger > for complex code. Debugging C/C++ programs can leave you feeling lost > and > disoriented. TotalView can help you find your way. Available on major > UNIX > and Linux platforms. Try it free. www.etnus.com > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Jboss Boot lib jars
Ok, this makes sense .. can't we list even if remote using WebDav? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Dillon Sent: Friday, March 07, 2003 4:07 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Jboss Boot lib jars The jars which are hardcoded in Main are references to jars which are required to load up the server. We can not assume that those jars are on the local file system and thus can not query a directory to discover which jars need to be loaded. If you would rather not have them hardcoded then perhaps an external property file would work. We certainly do not want to be bound to the file system again. --jason On Saturday, March 8, 2003, at 03:40 AM, Jeff Haynie wrote: > Is there any reason we need to hardcode the jars that are included in > the lib directory? (in org.jboss.Main) > > Can't we just put all the *.jars under /lib into the class > loader on boot? > > > Jeff > > > > > --- > This SF.net email is sponsored by: Etnus, makers of TotalView, The > debugger > for complex code. Debugging C/C++ programs can leave you feeling lost > and > disoriented. TotalView can help you find your way. Available on major > UNIX > and Linux platforms. Try it free. www.etnus.com > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Jboss Boot lib jars
Is there any reason we need to hardcode the jars that are included in the lib directory? (in org.jboss.Main) Can't we just put all the *.jars under /lib into the class loader on boot? Jeff --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: Error ..
Add jboss-common-client.jar on your path -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of hae loong chan Sent: Wednesday, March 05, 2003 8:36 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Re: Error .. hi all, After deployed firstejb.jar successfully into /opt/jboss/server/default/deploy, i complied and ran the FirstClient.class (please view attached FirstClient.java) and got the error message below. am i missing any .jar in my jboss deployment? command to run the FirstClient.class=> java -classpath .:/opt/jboss/client/jboss-j2ee.jar:/opt/jboss/client/jnp-client.jar client.FirstClient result after running the above command => Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/logging/Logger at org.jnp.interfaces.NamingContext.(NamingContext.java:95) at org.jnp.interfaces.NamingContextFactory.getInitialContext(NamingContextF actory.java:42) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243) at javax.naming.InitialContext.init(InitialContext.java:219) at javax.naming.InitialContext.(InitialContext.java:195) at client.FirstClient.main(FirstClient.java:22) --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss remoting
Yes, the class downloading is inefficient and has some large room for improvement. However, to be noted, that it will only download classes from the remote side if the class doesn't exists locally (or at least isn't visible). This is a little more efficient, as I remember, than RMI where the RMIClassLoader will automatically pull down all classes from remote. If we can somehow compose an object dependency graph when a class is required, we could further optimize this even more. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Tuesday, March 04, 2003 10:32 AM To: Jboss-Dev Subject: [JBoss-dev] jboss remoting Hey all, I can see why David was so excited about the new JBoss Remoting framework that Jeff Haynie and Tom Elrod wrote. I had dinner with Jeff in Boston last night and over a few beers he discussed in detail their design and features the framework provides. Jeff/Tom, please correct me where I'm wrong here. Some of the features I remember him discussing: 1. As RMI provides class downloading when the client does not have classes available, so does the JBoss remoting framework. The difference is that JBoss remoting supports multiple protocols. HTTP, SOAP, Socket based, etc... 2. Callbacks are supported and abstracted seemlessly. This will be especially important to JMS. 3. Management services. You can query to obtain a whole map of your network. 4. Find any jboss remoted object by providing a URI or even a query string. My guess of what needs work: 1. We need to abstract how references are created and marshalled. i.e., an EJB method that returns a reference to, or collection of other different EJBs. We need to make sure that these references point to the correct transport layer as they were invoked on. 2. The class downloading protocol seems a bit inefficient. The cool thing about this framework is that it is being used in production at Jeff's company so we know this shit must work :) All and all this is really gonna be great for 4.0. I'd really like to commend Jeff and Tom on a job well done. I'm looking forward to integrating AOP with this new framework. Bill --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] stop using JDK 1.4 for development
The problem really is with me - I fess up. Bill's mad because I broke the build twice this week by inadvertantly checking in code (throwing an exception that is the new overloaded version in 1.4) that only compiles on 1.4. Unfortunately, my whole work and home environment *DO* require 1.4 and only works under 1.4 - so I sometimes forget to re-set my path to JDK1.3 when I compile. So, it compiles fine under 1.4. I'm changing my jboss build environment to force my path and JDK to 1.3 before it runs. Maybe be can update the build.bat/.sh to automatically do this (or at least check the version before you compile) and that would fix this problem for everyone? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Jencks Sent: Friday, February 28, 2003 10:16 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] stop using JDK 1.4 for development I'd prefer to have a reliable way to report these problems, since I don't consider it realistic for me to develop on 1.3.1. How do you detect them? For the particular problem of nested exceptions, I think we should always use the jboss NestedThrowable stuff Jason wrote since it provides a much more reasonable stack trace. Dain and I made as much as we could find of the jca and jta frameworks use this with good results. How could we make this better known and popularize it? thanks david jencks On 2003.02.28 08:42 Bill Burke wrote: > There have been a lot of build breakages lately because people are > using JDK 1.4 features and they break in JDK 1.3 builds. WE STILL > SUPPORT JDK 1.3. My suggestion? Stop developing JBOss with jdk 1.4 > and develop with 1.3. > > Please stop the sloppiness. > > Bill > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] stop using JDK 1.4 for development
What's the reason to support JDK1.3 -- just asking, not against it. We've been using 1.4.1 for a good while now and it seems to be much better in performance and stability. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of danch Sent: Friday, February 28, 2003 9:30 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] stop using JDK 1.4 for development There's a big difference between supporting 1.4 and _not_ supporting 1.3 Matt Munz wrote: > Bill, > > I thought JBoss was going to support 1.4. Is this not the case? > > - Matt > > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED] > Sent: Fri 2/28/2003 8:42 AM > To: Jboss-Dev > Cc: > Subject: [JBoss-dev] stop using JDK 1.4 for development > > > > There have been a lot of build breakages lately because people are using JDK > 1.4 features and they break in JDK 1.3 builds. WE STILL SUPPORT JDK 1.3. > My suggestion? Stop developing JBOss with jdk 1.4 and develop with > 1.3. > > Please stop the sloppiness. > > Bill > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Eclipse is so amazing...
If you like Eclipse, IntelliJ blows it away. It's not free, but cheap and much more mature than Eclipse. I used Eclipse, but enjoy IntelliJ much more. (Not trying to start a holy war, just giving you another option to look at it you enjoy Eclipse...) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Wednesday, February 26, 2003 1:36 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Eclipse is so amazing... +1 I use it all them time. The Refactoring support and the Quick Assist features rock. Regards, Hiram --- Jason Dillon <[EMAIL PROTECTED]> wrote: > I can not believe how fast, intelligent and > functional this little IDE. > I have tears in my eyes I am so pleased. Okay > perhaps I need to get > out more... but still. I think I am going to have > to say goodbye to > XEmacs. Perhaps I am just getting old and lazy... > > --jason > > > > --- > This SF.net email is sponsored by: Scholarships for > Techies! > Can't afford IT training? All 2003 ictp students > receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, > Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > ___ > Jboss-development mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
Oh, I buy into it - and I'm neither for OR against what David is saying. I'm merely saying you should separate the concerns - but it seems like that is obvious and redudant (although not so apparent with all the back in forth) to you. As you know, I don't work for Jboss Group. I'm just merely trying to help out on my own *free time* and try and help make this a better product with what little value I can add. Sorry I stepped into the flames. I was hoping to enlighten a little bit to the fact that you could push some of this stuff into the remoting stuff that tom and I worked on. Jeff > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > Jeff Haynie > Sent: Friday, February 21, 2003 6:15 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is really really bad > > > Yes - but you guys don't seem to buy into it otherwise you won't be > talking about where and how tx or remoting should go into AOP. > > Maybe I'm missing something. > I'm not understanding you. I certainly buy into it and am implementing stuff (albeit slowly). Whether you and David buy into it is irrelevent. The vision is set. THis is where we're going. The whole point is isolation and being able to dynamically remote or not remote with any protocol you want. IMHO, Davids implementation for tx right now doesn't allow for this isolation. He disagrees. So what? We disagree. Eventually it will all flush out and either David and/or I will end up rewriting everything. My bet David gets there first since I've got A.D.D. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Bill Burke > Sent: Friday, February 21, 2003 6:09 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is really really bad > > > > > > I personally don't think AOP should have anything related to > > transactions, remoting, etc. I think that should be pushed up into > > the > > > functional areas that apply those specific semantics to the > > subsystems > > > since they are quite different depending on the subsystem (JMS, EJB, > > etc) and location (local,remote). > > > > Where have you been? Marc has been talking about creating an AOP > framework and services on top of this framework since the fall. The > whole point is to break ourselves away from EJB and isolate and > abstract out distribution infrastructure even more from a coding > perspective. > > Bill > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Hiram Chirino > > Sent: Friday, February 21, 2003 5:17 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is really really bad > > > > > > > > I have to disagree. Take a higher level look at the > > basics: All client proxies have a dependency on their corresponsing > > server side stub. You can't mix a different proxys and stub types. > > Therefore it is ok for a client side interceptor to have a > > dependency on the server side interceptor. > > > > Can you describe your AOP problem in more detail. How > > are you going to be remoting POJO with AOP?? With a > > proxy? Who will create the proxy objet? > > > > Regards, > > Hiram > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > Ok, maybe I shouldn't have said "fatally flawed". > > > But again, my gut tells > > > me that it is bad to have a dependency between > > > server and client > > > interceptors if it is not absolutely needed. > > > > > > > -Original Message- > > > > From: > > > [EMAIL PROTECTED] > > > > > > > > > [mailto:[EMAIL PROTECTED] > > > Behalf Of Bill > > > > Burke > > > > Sent: Friday, February 21, 2003 4:12 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] TxInterceptor split is > > > really really bad > > > > > > > > > > > > I've been thinking and should have posted this > > > before. Your design is > > > > fataly flawed when I start applying it to the AOP > > > framework. Your design > > > > assumes that there is a proxy sitting in front of > > > everything. In AOP this > > > > is not the case. If you look at > > > > varia/src/org/jboss/aop/plugins/TxSupport.java > > > you'll see that I had to > > > > combine the
RE: [JBoss-dev] TxInterceptor split is really really bad
Yes - but you guys don't seem to buy into it otherwise you won't be talking about where and how tx or remoting should go into AOP. Maybe I'm missing something. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, February 21, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad > > I personally don't think AOP should have anything related to > transactions, remoting, etc. I think that should be pushed up into the > functional areas that apply those specific semantics to the subsystems > since they are quite different depending on the subsystem (JMS, EJB, > etc) and location (local,remote). > Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective. Bill > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Hiram Chirino > Sent: Friday, February 21, 2003 5:17 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is really really bad > > > > I have to disagree. Take a higher level look at the > basics: All client proxies have a dependency on their corresponsing > server side stub. You can't mix a different proxys and stub types. > Therefore it is ok for a client side interceptor to have a dependency > on the server side interceptor. > > Can you describe your AOP problem in more detail. How > are you going to be remoting POJO with AOP?? With a > proxy? Who will create the proxy objet? > > Regards, > Hiram > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > Ok, maybe I shouldn't have said "fatally flawed". > > But again, my gut tells > > me that it is bad to have a dependency between > > server and client > > interceptors if it is not absolutely needed. > > > > > -Original Message- > > > From: > > [EMAIL PROTECTED] > > > > > > [mailto:[EMAIL PROTECTED] > > Behalf Of Bill > > > Burke > > > Sent: Friday, February 21, 2003 4:12 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] TxInterceptor split is > > really really bad > > > > > > > > > I've been thinking and should have posted this > > before. Your design is > > > fataly flawed when I start applying it to the AOP > > framework. Your design > > > assumes that there is a proxy sitting in front of > > everything. In AOP this > > > is not the case. If you look at > > > varia/src/org/jboss/aop/plugins/TxSupport.java > > you'll see that I had to > > > combine the clientInvoke and serverInvoke into one > > method because there is > > > no proxy object between the application code and > > the object instance. > > > > > > Ok...no problem you sayWell, think of what > > happens when the app > > > developer decides to remote an AOP'd object. I > > will have to have > > > 2 sets of > > > interceptor chains and have to figure out whether > > the call is a > > > remote call > > > or local. Well, I guess I could insert a flag > > into the Invocation on > > > whether the call went through a proxy or not. But > > do you see where I'm > > > going? I don't think its a good design to rely on > > the client to handle > > > transaction semantics. I don't think its a good > > idea for the "server" to > > > have to rely on client logic unless it really has > > to. > > > > > > All and all, my gut tells me that the current > > client/tx design will cause > > > problems. I want interceptor designers in general > > to avoid this kind of > > > dependency. > > > > > > Bill > > > > > > > -Original Message- > > > > From: > > [EMAIL PROTECTED] > > > > > > > [mailto:[EMAIL PROTECTED] > > Behalf Of David > > > > Jencks > > > > Sent: Wednesday, February 19, 2003 11:02 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] TxInterceptor split is > > really really good > > > > > > > > > > > > On 2003.02.19 09:37 Bill Burke wrote: > > > > > > > > > > > > What you implemented is fine. My only > > problem with it is that I > > > > > > think it is more logical to let the server > > decide if it needs the > > > > > > tx, and that I think the registration > > callback could be avoided > > > > > > (with minimal redundant client side > > bookkeeping) even if the > > > > > > decision is made on the server side. > > > > > > > > > > > > I got the impression that this > > implementation would also be used > > > > > > in the other invokers, and that made me > > worry about CORBA > > > > > > interoperability. If this approach will not > > be used with the IIOP > > > > > > invoker, I have no problem with it. > > > > > > > > > > > > > > > > Yes this was my exact worry and still is. > > That we'll have to have a > > > > > different set of interceptors on the server > > side for different > > > > > transports. > > > > > This is unexceptable because we want
RE: [JBoss-dev] TxInterceptor split is really really bad
I think AOP has a separate functional requirement from Remoting and should be separated. Remoting depends (potentially) on AOP. AOP should be the instrumenting, invocation and interception framework. Remoting should then add any semantics for transport and discovery. Individual subsystems (JMX,JMS,EJB), then have a client side proxy (of some sorts, yet to be determined) and a server side invocation handler that know how to convert the local invocation into a remote one using the remoting framework (CLIENT) and know how to take the remote invocation and create a local invocation and return it (SERVER). We should de-couple them into their respective modules of responsibility and functionality. I think the remote tx stuff should be an AOP interceptor that is applied to the EJB client side side remote proxy (that makes the client invoker via remoting) by adding the TX to the invocation payload and then on the other side extracting the TX from the invocation and applying... I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke <[EMAIL PROTECTED]> wrote: > Ok, maybe I shouldn't have said "fatally flawed". > But again, my gut tells > me that it is bad to have a dependency between > server and client > interceptors if it is not absolutely needed. > > > -Original Message- > > From: > [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > Behalf Of Bill > > Burke > > Sent: Friday, February 21, 2003 4:12 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is > really really bad > > > > > > I've been thinking and should have posted this > before. Your design is > > fataly flawed when I start applying it to the AOP > framework. Your design > > assumes that there is a proxy sitting in front of > everything. In AOP this > > is not the case. If you look at > > varia/src/org/jboss/aop/plugins/TxSupport.java > you'll see that I had to > > combine the clientInvoke and serverInvoke into one > method because there is > > no proxy object between the application code and > the object instance. > > > > Ok...no problem you sayWell, think of what > happens when the app > > developer decides to remote an AOP'd object. I > will have to have > > 2 sets of > > interceptor chains and have to figure out whether > the call is a > > remote call > > or local. Well, I guess I could insert a flag > into the Invocation on > > whether the call went through a proxy or not. But > do you see where I'm > > going? I don't think its a good design to rely on > the client to handle > > transaction semantics. I don't think its a good > idea for the "server" to > > have to rely on client logic unless it really has > to. > > > > All and all, my gut tells me that the current > client/tx design will cause > > problems. I want interceptor designers in general > to avoid this kind of > > dependency. > > > > Bill > > > > > -Original Message- > > > From: > [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > Behalf Of David > > > Jencks > > > Sent: Wednesday, February 19, 2003 11:02 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] TxInterceptor split is > really really good > > > > > > > > > On 2003.02.19 09:37 Bill Burke wrote: > > > > > > > > > > What you implemented is fine. My only > problem with it is that I > > > > > think it is more logical to let the server > decide if it needs the > > > > > tx, and that I think the registration > callback could be avoided > > > > > (with minimal redundant client side > bookkeeping) even if the > > > > > decision is made on the server side. > > > > > > > > > > I got the impression that this > implementation would also be used > > > > > in the other invokers, and that made me > worry about CORBA > > > > > interoperability. If this approach will not > be used with the IIOP > > > > > invoker, I have no problem with it. > > > > > > > > > > > > > Yes this was my exact worry and still is. > That we'll have to have a > > > > different set of interceptors on the server > side for different > > > > transport
RE: [JBoss-dev] Jboss-mx errors
Title: Message OK, this is fixed. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff HaynieSent: Friday, February 21, 2003 12:54 PMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] Jboss-mx errors i did a brand new checkout into a clean directory. i'll fix the build. thanks, -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill BurkeSent: Friday, February 21, 2003 12:49 PMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] Jboss-mx errors jmx/build.xml probably needs to reference dom4j.jar. I just check out last night at 10 pm with no problems. Did you do an update instead of a clean checkout? I don't think update grabs thirdparty jars for some reason. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Jeff HaynieSent: Friday, February 21, 2003 12:43 PMTo: [EMAIL PROTECTED]Subject: [JBoss-dev] Jboss-mx errors I'm getting a bunch of these errors while building fresh checkout of jboss-mx from HEAD. Anyone have any ideas? [execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:37: package org.dom4j does not exist[execmodules] import org.dom4j.Document;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:38: package org.dom4j does not exist[execmodules] import org.dom4j.DocumentException;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:39: package org.dom4j does not exist[execmodules] import org.dom4j.Element;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:40: package org.dom4j.iodoes not exist[execmodules] import org.dom4j.io.SAXReader;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:63: cannot resolve symbol [execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] private Element element;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:78: cannot resolve symbol [execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] public JBossXMBean10(String mmbClassName, String resourceClassName, Element element, Map properties)[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:127: cannot resolve symbol[execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] protected Descriptor getDescriptor(final Element parent, final String infoName, final String type) throws NotCompliantMBeanException[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean12.java:9: package org.dom4j does not exist[execmodules] import org.dom4j.Attribute;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean12.java:10: package org.dom4j doe
RE: [JBoss-dev] Jboss-mx errors
Title: Message i did a brand new checkout into a clean directory. i'll fix the build. thanks, -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill BurkeSent: Friday, February 21, 2003 12:49 PMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] Jboss-mx errors jmx/build.xml probably needs to reference dom4j.jar. I just check out last night at 10 pm with no problems. Did you do an update instead of a clean checkout? I don't think update grabs thirdparty jars for some reason. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Jeff HaynieSent: Friday, February 21, 2003 12:43 PMTo: [EMAIL PROTECTED]Subject: [JBoss-dev] Jboss-mx errors I'm getting a bunch of these errors while building fresh checkout of jboss-mx from HEAD. Anyone have any ideas? [execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:37: package org.dom4j does not exist[execmodules] import org.dom4j.Document;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:38: package org.dom4j does not exist[execmodules] import org.dom4j.DocumentException;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:39: package org.dom4j does not exist[execmodules] import org.dom4j.Element;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:40: package org.dom4j.iodoes not exist[execmodules] import org.dom4j.io.SAXReader;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:63: cannot resolve symbol [execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] private Element element;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:78: cannot resolve symbol [execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] public JBossXMBean10(String mmbClassName, String resourceClassName, Element element, Map properties)[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:127: cannot resolve symbol[execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] protected Descriptor getDescriptor(final Element parent, final String infoName, final String type) throws NotCompliantMBeanException[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean12.java:9: package org.dom4j does not exist[execmodules] import org.dom4j.Attribute;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean12.java:10: package org.dom4j doe
[JBoss-dev] Jboss-mx errors
I'm getting a bunch of these errors while building fresh checkout of jboss-mx from HEAD. Anyone have any ideas? [execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:37: package org.dom4j does not exist[execmodules] import org.dom4j.Document;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:38: package org.dom4j does not exist[execmodules] import org.dom4j.DocumentException;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:39: package org.dom4j does not exist[execmodules] import org.dom4j.Element;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:40: package org.dom4j.iodoes not exist[execmodules] import org.dom4j.io.SAXReader;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:63: cannot resolve symbol [execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] private Element element;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:78: cannot resolve symbol [execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] public JBossXMBean10(String mmbClassName, String resourceClassName, Element element, Map properties)[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:127: cannot resolve symbol[execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] protected Descriptor getDescriptor(final Element parent, final String infoName, final String type) throws NotCompliantMBeanException[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean12.java:9: package org.dom4j does not exist[execmodules] import org.dom4j.Attribute;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean12.java:10: package org.dom4j doe
RE: [JBoss-dev] JBoss Remoting Commit
lementations) would be registered in the jboss-service.xml *before* any of the subsystems along with the subsystems supported. Then, the Connector will create the appropriate server side ServerInvocationHandler instances and register them with the ServerInvoker. The other important part of all this is the InvokerLocator, which is a URI-like string that describes where the physical transport can be reached. This is broadcasted as part of the detection framework - so that remote servers can be located based on their InvokerLocator string. Then, as a client needs to "find a server", it can query the NetworkRegistry for any servers (that match the protocol, etc.) to create the ClientInvoker (via the InvokerRegistry) back to the server. So, you can either us discovery or directly using the URI make invocations against a remote server - and it's painless. Discovery is pluggable, so right now we just have Multicast. Tom is currently working on Unicast/HA JNDI. We would like to add UDDI as well. 5. Since I think it is possible that jmx could be used without aop and aop without jmx, I'd like to suggest that we make a new module "invocation" that has the interceptor interface, and the Invocation and InvocationResponse objects in it. Otherwise I don't see how to unify our view of these fundamental classes without intruducing artificial dependencies. JGH: I like this idea personally. I'd like to get to work on the interceptor stuff I mentioned, so I'd like to get comments on this soon so at least I'll know how much I'll have to fight:- JGH: Can we start a separate development forum to continue this?? BILL/MARC?? This is awesome work. JGH: Thanks! Thanks again david jencks On 2003.02.19 00:54 Jeff Haynie wrote: > I commited the jboss-remoting code tonight. There is now a separate > module named jboss-remoting, and it is aliased in jboss-mx and > jboss-head (because mx needs it). > > It looks like all 3 modules are compiling fine. There is more work > that Tom and I are doing this week to try and wrap up the initial > testing - however, the code should compile fine and the code isn't yet > referenced at all anywhere in the server so shouldn't cause any > problems. If it does cause problems in the next day or so, please let > me or Tom Elrod > ([EMAIL PROTECTED]) if you have any issues - or just fix them > and let me and him know. > > -Jeff > > http://www.freeroller.net/page/jhaynie > > > > > Message > > > I commited > the > jboss-remoting code tonight. There is now a separate module named > jboss-remoting, and it is aliased in jboss-mx and jboss-head (because mx > needs > it). > > It looks like > all 3 > modules are compiling fine. There is more work that Tom and I are > doing > this week to try and wrap up the initial testing - however, the code > should > compile fine and the code isn't yet referenced at all anywhere in the > server so > shouldn't cause any problems. If it does cause problems in the next > day or > so, please let me or Tom Elrod ( href="mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]) if > you > have any issues - or just fix them and let me and him know. > > > class=323323305-19022003>-Jeff > class=323323305-19022003> > href="http://www.freeroller.net/page/jhaynie";>http://www.freeroller.net/ page/jhaynie > > > --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss Remoting Commit
Title: Message I commited the jboss-remoting code tonight. There is now a separate module named jboss-remoting, and it is aliased in jboss-mx and jboss-head (because mx needs it). It looks like all 3 modules are compiling fine. There is more work that Tom and I are doing this week to try and wrap up the initial testing - however, the code should compile fine and the code isn't yet referenced at all anywhere in the server so shouldn't cause any problems. If it does cause problems in the next day or so, please let me or Tom Elrod ([EMAIL PROTECTED]) if you have any issues - or just fix them and let me and him know. -Jeff http://www.freeroller.net/page/jhaynie
RE: [JBoss-dev] jmx remoting + copyright in a jbossmx file
Yes, this is my fault and will resolve. My IDE automatically puts those at the top of every new class and I have to remember to delete them and replace for JBOSS code. This code is part of JBOSS and not part of Vocalocity. I will remove ASAP. Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Anatoly Akkerman Sent: Tuesday, February 18, 2003 5:57 PM To: JBoss-Dev Subject: [JBoss-dev] jmx remoting + copyright in a jbossmx file Hi, I've been browsing the HEAD in CVS to find out what the status of JMX remoting is. It appears that significant pieces have been implemented. I was hoping to use some of this stuff decoupled from JBoss itself, is it usable already? (I understand that classloading is a work in progress, can this work if all classes are available in both MBean servers?) And another thing I've noticed in one of the files, you might want to fix it. This is from org/jboss/mx/remote/connector/socket/SocketExecutor.java /** * @(#)$Id: SocketExecutor.java,v 1.3 2003/01/02 02:34:45 jhaynie Exp $ * * This code is PROPRIETARY AND CONFIDENTIAL to Vocalocity, Inc. * -- DO NOT RE-DISTRIBUTE THIS SOURCE CODE WITHOUT EXPRESS PERMISSION. -- * * This source code is Copyright (c) 2001-2002 by Vocalocity, Inc. * All Rights Reserved. * * The source code for this program is not published or * otherwise divested of its trade secrets, irrespective * of what has been deposited with the US Copyright Office. * */ Anatoly. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ThreadPooling in JMX? Its broken
What happens in the case the executing thread doesn't know he's executing on a thread pool thread - such as that another caller is calling a method on an object via a thread pool? In this case, you thread local variables wouldn't work -- in which case, thread locals are pointless, no? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Scott M Stark Sent: Thursday, January 16, 2003 1:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] ThreadPooling in JMX? Its broken Bull, the threads which have access to a thread local may have nothing to do with the thread pool. You don't know why a thread local was introduced just because you manage threads. This is a bit like saying you should be able to clear all variables declared in the sceop of package names x.y.threads. Create you own ThreadPoolLocal for the semantics your talking about. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Bill Burke" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 16, 2003 9:50 AM Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken > Sure there should. For people that want to do thread pooling! > --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] ThreadPooling in JMX? Its broken
Why don't we just create on enter and then clear thread locals in the finally of the run in the threadpool? If there's any thread local variables in the executing thread, they could then be set in the executing thread pool thread, and then the thread pool thread could remove them upon exiting? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Burke Sent: Thursday, January 16, 2003 12:51 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken Sure there should. For people that want to do thread pooling! > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > Scott M Stark > Sent: Thursday, January 16, 2003 12:42 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] ThreadPooling in JMX? Its broken > > > Certainly not and there should not be. The content of the thread > local has to > be controlled in the scope in which it exists. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "Bill Burke" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, January 16, 2003 5:35 AM > Subject: RE: [JBoss-dev] ThreadPooling in JMX? Its broken > > > > I don't think there's any way to clear the thread locals. All those > > variables are package protected and there seems to be no way to > clear all > > threadlocals > > > > --- > This SF.NET email is sponsored by: Thawte.com > Understand how to protect your customers personal information by > implementing > SSL on your Apache Web Server. Click here to get our FREE Thawte Apache > Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: Thawte.com Understand how to protect your customers personal information by implementing SSL on your Apache Web Server. Click here to get our FREE Thawte Apache Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [ jboss-Bugs-668710 ] jboss.org vilolaties w3c-standards and doesn't render right
Is this is JOKE? I think I'd prefer to spend my time on AOP / JB4. geez.. ... ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of SourceForge.net Sent: Wednesday, January 15, 2003 3:27 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [ jboss-Bugs-668710 ] jboss.org vilolaties w3c-standards and doesn't render right Bugs item #668710, was opened at 2003-01-15 21:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=668710&grou p_id=22866 Category: JBossDoc Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Marius Kotsbak (mkotsbak) Assigned to: Nobody/Anonymous (nobody) Summary: jboss.org vilolaties w3c-standards and doesn't render right Initial Comment: jboss.org has 56 violations of the "HTML 4.01 Transitional" that it is supposed to conform to according to: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.jboss.org%2F&charset= %28detect+automatically%29&doctype=%28detect+automatically%29&verbose=1 Another validator: http://www.htmlhelp.com/cgi-bin/validate.cgi?url=http://www.jboss.org/&w arnings=yes&input=yes This gives the result that I have attached a screenshot of, the menu is repeated 1/4 to the right of the menu in both mozilla and opera browsers (havent't checked others). Please update the webpage so it follows the web standards as jboss follows sun's EJB standards. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=668710&grou p_id=22866 --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
