[JBoss-dev] [JBoss JIRA] Created: (JBREM-53) Problem during classloading on certain classloaders

2005-02-01 Thread Jeff Haynie (JIRA)
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

2005-01-28 Thread Jeff Haynie (JIRA)
 [ 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

2005-01-26 Thread Jeff Haynie (JIRA)
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] [ jboss-Bugs-871649 ] Problem with source of JMX Notifications

2004-01-06 Thread Jeff Haynie
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=detailatid=376685aid=871649group_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 cannot setSource() a normal object

Re: [JBoss-dev] Remoting and NAT traversal, advanced network

2004-01-06 Thread Jeff Haynie
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=1278alloc_id=3371op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] New JBoss Monitoring services

2004-01-06 Thread Jeff Haynie
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

?xml version=1.0 encoding=UTF-8?
server
mbean code=org.jboss.monitor.ThresholdMonitor
   name=jboss.monitor:service=FreeMemory
  attribute name=MonitorNameFreeMemory
Monitor/attribute
  attribute
   

name=ObservedObjectjboss.system:type=ServerInfo/attribute
 

  attribute
name=ObservedAttributeFreeMemory/attribute
  attribute name=Threshold100/attribute
  attribute name=CompareTo1/attribute
  attribute name=Period1000/attribute
  attribute name=Enabledtrue/attribute
  depends-list
optional-attribute-name=AlertListeners
   

depends-list-elementjboss.alerts:service=ConsoleAlertListener/depends
 

-list-element

   

depends-list-elementjboss.alerts:service=EmailAlertListener/depends-l
 

ist-element
  /depends-list
/mbean
/server
Let's walk through each attribute:

  attribute
name=MonitorNameFreeMemory/attribute
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.

  attribute

   

name=ObservedObjectjboss.system:type=ServerInfo/attribute
 

  attribute
name=ObservedAttributeFreeMemory/attribute
These are the MBean and the MBean attribute this
monitor will watch.  If
the MBean is a ServiceMBean then you should make
this a depends 
optional-attribute so that this monitor doesn't
start before the
watched MBean is loaded.

  attribute name=Threshold100/attribute
  attribute name=CompareTo1/attribute
The 

Re: [JBoss-dev] New JBoss Monitoring services

2004-01-06 Thread Jeff Haynie
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

?xml version=1.0 encoding=UTF-8?
server
mbean code=org.jboss.monitor.ThresholdMonitor
   name=jboss.monitor:service=FreeMemory
  attribute name=MonitorNameFreeMemory
Monitor/attribute
  attribute
   

name=ObservedObjectjboss.system:type=ServerInfo/attribute
 

  attribute
name=ObservedAttributeFreeMemory/attribute
  attribute name=Threshold100/attribute
  attribute name=CompareTo1/attribute
  attribute name=Period1000/attribute
  attribute name=Enabledtrue/attribute
  depends-list
optional-attribute-name=AlertListeners
   

depends-list-elementjboss.alerts:service=ConsoleAlertListener/depends
 

-list-element

   

depends-list-elementjboss.alerts:service=EmailAlertListener/depends-l
 

ist-element
  /depends-list
/mbean
/server
Let's walk through each attribute:

  attribute
name=MonitorNameFreeMemory/attribute
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.

  attribute

   

name=ObservedObjectjboss.system:type=ServerInfo/attribute
 

  attribute
name=ObservedAttributeFreeMemory/attribute
These are the MBean and the MBean attribute this
monitor will watch.  If
the MBean is a ServiceMBean then you should make
this a depends 
optional-attribute so that this monitor 

Re: [JBoss-dev] New JBoss Monitoring services

2004-01-06 Thread Jeff Haynie
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=1278alloc_id=3371op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] Remoting and NAT traversal, advanced network

2004-01-05 Thread Jeff Haynie
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=1278alloc_id=3371op=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

2004-01-05 Thread Jeff Haynie
C:\cvs\jboss-3.2\buildant
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\buildnotepad 
C:\cvs\jboss-3.2\tools\etc\buildmagic\buildmagic.ent

I updated buildmagic.ant

property name=buildmagic.ant.baseversion value=1.6/

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=1278alloc_id=3371op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] Build not working with Ant 1.6.0

2004-01-05 Thread Jeff Haynie
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:

 condition property=buildmagic.ant.compatible
   and
 contains string=${ant.version} 
	substring=Ant version ${buildmagic.ant.baseversion}/
   /and
 /condition

 fail unless=buildmagic.ant.compatible

 Unsupported Ant version:

   ${ant.version}

 Please install a version which is compatible with Ant
${buildmagic.ant.baseversion}.
 /fail

Regards,
Adrian
On Mon, 2004-01-05 at 22:59, Jeff Haynie wrote:
 

C:\cvs\jboss-3.2\buildant
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\buildnotepad 
C:\cvs\jboss-3.2\tools\etc\buildmagic\buildmagic.ent

I updated buildmagic.ant

property name=buildmagic.ant.baseversion value=1.6/

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=1278alloc_id=3371op=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=1278alloc_id=3371op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] Remoting and NAT traversal, advanced network

2004-01-05 Thread Jeff Haynie
In the remoting framework, there are three main components: a transport, 
a detector and a network registry.  (among others .. but these are the 
biggest)

The transport encapsulates the client and server components necessary 
for communication for a given protocol between two endpoints.

The detector is a specific protocol/mechanism for handling discovery and 
failure of zero or more endpoints based on a domain (or a cluster, 
partition, whatever you'd like to call it - a logical grouping of 
machines with the same name).

For transports, we have sockets (TCP), RMI, SOAP.

For detectors, we have multicast, JNDI.

The next major component is the network registry which receives 
detection notifications (or you can call it directly to enlist servers) 
which keeps a network map of all machines (and their identity and valid 
transports and how to communicate with them) within the same logical domain.

In JMX remoting, a simple proxy is created for the JMX subsystem (you 
can have other subsystems such as AOP, JMS, etc.) which uses a transport 
(unknown to the proxy) to communicate with the remote MBeanServer.

This allows you to mix and match transports, detection/failure 
mechanisms and subsystems that use the framework.

In AOP Remoting, you can simply instrument an object, given a remote 
locator (which could be obtained via detection) and then make remote 
method calls against it w/o RMI stubs, etc.

We make heavy use of something called an MBeanTracker which is in JMX 
Remoting.

You can give the mbean tracker a set of interfaces, query expression, 
and any combination/ lack thereof and he will automatically give you 
back a callback for things such as register, unregister, notification 
and a MBeanLocator which can be turned into a proxy to that object.

For example:

MBeanTracker tracker=new MBeanTracker(getServer(), new 
Class[]{Server.class}, null, false, null, true, new 
MBeanTrackerActionAdapter()
{
 public void mbeanRegistered (MBeanLocator locator)
 {
 System.out.println(I found a new JBoss server at: +locator+ on 
the network);
   
 // cast to a server proxy that implements the Server interface
 Server server = (Server)locator.narrow(Server.class);
 
 // look ma... no hands, I just shutdown your jboss server remotely
 server.shutdown();
 }
 public void mbeanUnregistered (MBeanLocator locator)
 {
 System.out.println(I lost a JBoss server at: +locator+ on the 
network);
 }
 public void mbeanNotification (MBeanLocator locator, Notification 
notification, Object handback)
 {
 System.out.println(JBoss server at: +locator+ sent a 
notification: +notification);
 }
});

It's as simple as that.  You can deal with network transparency (in a 
novel way), failure, detection, etc. in short-order - with very little 
code - but very very powerful.

And, no Marc, this isn't relegated to just JMX as Bill demonstrates with 
AOP Remoting.  This should be used for JMS, EJB and all the other 
subsystem layers.  ;)

Jeff



Scott M Stark wrote:

We use system properties that allow client environments to override
the URL used to connect to in the RMI/HTTP transport for this
issue.
What is the detection notification you are talking about here? I have
not looked at the remoting code much so describe the network traffic.

Scott Stark
Chief Technology Officer
JBoss Group, LLC
 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Haynie
Sent: Monday, January 05, 2004 2:04 PM
To: [EMAIL PROTECTED]
Subject: [JBoss-dev] Remoting and NAT traversal, advanced network

We have a customer that needs to use JBoss Remoting / JMX Remoting in a
fairly complex, although not unusual, network configuration.
Right now, we don't well support dynamic / NAT traversals for remoting
either in detection or transport.  We basically send the local machines
address (which bind address is configurable) as part of the detection
notification to the remote machine.  This works fine on a local subnet.
In the case of a remote subnet, you can use the JNDI detection which
will bind the entry into a remote (or local) JNDI context which can then
be browsed by any network that can reach the JNDI server.
In cases where NAT is being used (or potentially even DHCP, although
slightly different), we need to be able to send the detection annotated
with additional network interfaces, such as the public IP or hostname.  
Ideally, this could be a simple configuration that we would read /
lookup (maybe as simple as a system property) and the Identity could be
modified to include additional addresses (similar to InetAddress when
you have multiple NICs locally).  Then, the remote machine transport
could then try the primary address and then secondary addresses if the
primarily failed.

In addition, I wrote a SSHConnector that uses SSH tunneling (totally
dynamic, not setup except giving it the credentials) on both sides to do
SSH transport - I need

[JBoss-dev] ServiceController MBean unload ordering

2004-01-05 Thread Jeff Haynie
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=1278alloc_id=3371op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] Remoting and JMX Remoting Fixes

2004-01-04 Thread Jeff Haynie
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=1278alloc_id=3371op=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

2004-01-03 Thread Jeff Haynie
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=1278alloc_id=3371op=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=1278alloc_id=3371op=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

2004-01-03 Thread Jeff Haynie
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_id78alloc_id371op=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=1278alloc_id=3371op=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

2004-01-03 Thread Jeff Haynie
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_id78alloc_id371op=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=1278alloc_id=3371op=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

2003-12-10 Thread Jeff Haynie
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=detailatid=376688aid=858049group_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=detailatid=376688aid=858049group_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=1278alloc_id=3371op=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=1278alloc_id=3371op=click
___
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


Re: [JBoss-dev] several ThreadPool classes

2003-12-01 Thread Jeff Haynie
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] ManagementBean and RemoteMbeanServer

2003-06-17 Thread Jeff Haynie
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]

2003-04-04 Thread Jeff Haynie
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-
   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

RE: [JBoss-dev] JB4DR1 Deadline MAY 26

2003-04-03 Thread Jeff Haynie
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 TARGET FOR JBOSS4.0 DR1    MAY 26TH
  
  
   To meet this aggressive deadline, we need to set some dates.  
   There will be a functionality freeze, Monday, May 5th.  All new 
   functionality commits after May 5th 

RE: [JBoss-dev] JB4DR1 Deadline MAY 26

2003-04-03 Thread Jeff Haynie
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.
  
   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

RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-27 Thread Jeff Haynie

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] Regarding JBoss site

2003-03-27 Thread Jeff Haynie
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/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!

RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Jeff Haynie
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:

class-metadata name=234234 group=VERSIONED
class=org.jboss.test.aop.bean.VersionedPOJO
method name=get.*
  read-onlytrue/read-only
/method
/class-metadata

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


RE: [JBoss-dev] AOP versioned ACID objects 1st iteration

2003-03-26 Thread Jeff Haynie

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


[JBoss-dev] Jboss/David Vs. Sun/Goliath?

2003-03-20 Thread Jeff Haynie
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: Re[2]: [JBoss-dev] JBoss-3.2 build issues

2003-03-18 Thread Jeff Haynie
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] AOP Clustering 1st iteration

2003-03-18 Thread Jeff Haynie
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: [JBoss-dev] Naming a core module?

2003-03-09 Thread Jeff Haynie
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] [AUTOMATED] (HEAD) JBoss compilation failed

2003-03-08 Thread Jeff Haynie
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.
 
  Total time: 23 seconds
 
 
  ---
  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. 

RE: [JBoss-dev] Naming a core module?

2003-03-08 Thread Jeff Haynie
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


[JBoss-dev] Jboss Boot lib jars

2003-03-07 Thread Jeff Haynie
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 root/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] Jboss Boot lib jars

2003-03-07 Thread Jeff Haynie
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 root/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

2003-03-07 Thread Jeff Haynie
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 root/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




---
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

RE: [JBoss-dev] jboss remoting

2003-03-07 Thread Jeff Haynie
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 LETS 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] Re: Error ..

2003-03-05 Thread Jeff Haynie
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.clinit(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.init(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

2003-03-04 Thread Jeff Haynie
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

2003-02-28 Thread Jeff Haynie
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] stop using JDK 1.4 for development

2003-02-28 Thread Jeff Haynie
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] Eclipse is so amazing...

2003-02-26 Thread Jeff Haynie
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


[JBoss-dev] Jboss-mx errors

2003-02-21 Thread Jeff Haynie



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 doesnot 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

2003-02-21 Thread Jeff Haynie
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 doesnot 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] TxInterceptor split is really really bad

2003-02-21 Thread Jeff Haynie
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
transports.
This is unexceptable because we want each EJB
 to be able to
   listen to and
service calls from different transports at the
 same time.
   
David, I'm not suggesting to redesign your
 code, but is the 

RE: [JBoss-dev] TxInterceptor split is really really bad

2003-02-21 Thread Jeff Haynie
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 each EJB
  to be able to
listen to and
 service calls from different transports at the
  same time.

 David, I'm not suggesting to redesign your
  code, but is the design
 flexible
 enough so that we could switch to a
  server-side based design?
Iteration
 is
 a fine thing
   
I don't think we will have 

RE: [JBoss-dev] TxInterceptor split is really really bad

2003-02-21 Thread Jeff Haynie
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 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

RE: [JBoss-dev] JBoss Remoting Commit

2003-02-19 Thread Jeff Haynie
 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
  
  
 
 !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN 
 HTMLHEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; 
 charset=us-ascii TITLEMessage/TITLE
 
 META content=MSHTML 6.00.2800.1141 name=GENERATOR/HEAD BODY
 DIVFONT face=Arial size=2SPAN class=323323305-19022003I commited
 the 
 jboss-remoting code tonight.nbsp; There is now a separate module
named 
 jboss-remoting, and it is aliased in jboss-mx and jboss-head (because
mx
 needs 
 it)./SPAN/FONT/DIV
 DIVFONT face=Arial size=2/FONTnbsp;/DIV
 DIVSPAN class=323323305-19022003FONT face=Arial size=2It looks
like
 all 3 
 modules are compiling fine.nbsp; 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.nbsp; If it does cause problems in the
next
 day or 
 so, please let me or Tom Elrod (A 
 href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/A)
if
 you 
 have any issues - or just fix them and let me and him know.nbsp; 
 /FONT/SPAN/DIV
 DIV dir=ltr align=leftFONT face=Arial size=2/FONTnbsp;/DIV
 DIV dir=ltr align=leftFONT face=Arial size=2SPAN 
 class=323323305-19022003-Jeff/SPAN/FONT/DIV
 DIV dir=ltr align=leftFONT face=Arial size=2SPAN 
 class=323323305-19022003/SPAN/FONTnbsp;/DIV
 DIV dir=ltr align=leftFONT face=Arial size=2A 

href=http://www.freeroller.net/page/jhaynie;http://www.freeroller.net/
page/jhaynie/A/FONT/DIV
 DIV dir=ltr align=leftFONT face=Arial size=2/FONTnbsp;/DIV
 DIVnbsp;/DIV/BODY/HTML
 


---
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



RE: [JBoss-dev] jmx remoting + copyright in a jbossmx file

2003-02-18 Thread Jeff Haynie
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



[JBoss-dev] JBoss Remoting Commit

2003-02-18 Thread Jeff Haynie
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] ThreadPooling in JMX? Its broken

2003-01-16 Thread Jeff Haynie
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] ThreadPooling in JMX? Its broken

2003-01-16 Thread Jeff Haynie
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] [ jboss-Bugs-668710 ] jboss.org vilolaties w3c-standards and doesn't render right

2003-01-15 Thread Jeff Haynie
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=detailatid=376685aid=668710grou
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%2Fcharset=
%28detect+automatically%29doctype=%28detect+automatically%29verbose=1

Another validator:
http://www.htmlhelp.com/cgi-bin/validate.cgi?url=http://www.jboss.org/w
arnings=yesinput=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=detailatid=376685aid=668710grou
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