[JBoss-dev] NotificationBroadcaster for J2eeDeployerMBean
I was looking at JBoss 2.4 and noticed that org.jboss.deployment.J2eeDeployerMBean interface does not extend the javax.management.NotificationBroadcaster interface. My project needs this feature and if anyone hasn't already done it, I'd volunteer. Should I work from the 3.0 code base? Or if the J2eeDeployer hasn't changed that much, I could work from the 2.4? Let me know. Thank you. Frederick N. Brier Sr. Software Engineer Multideck Corporation ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Deployment Notifications in JBoss 3.0 changed
I had submitted some JMX deployment notification code (DeploymentNotification class and mods to the J2eeDeployer class) which was incorporated into JBoss 2.4x. I've just started migrating to JBoss 3.0 and noticed that the DeploymentInfo object is not passed in the Notification anymore, only the url data member is passed to the setUserData() method in MainDeployer.java. I specifically need the localUrl, but the other info was useful as well. This was so that I could open XML files that might exist within the deployed archive. The XML files contain SQL commands (to create additional indexes or load initial data into tables), create dynamic MBeans instances, and provide configuration data for currently running MBeans. As far as I can tell, changing the parameter of setUserData() to the di (DeploymentInfo) from just the URL (di.url) would only effect one line of code in the distribution. That would be line 459 in FarmMemberService.java from: URL lURL = (URL) pNotification.getUserData(); to: URL lURL = ((DeploymentInfo)pNotification.getUserData()).url; The other request is to move the sendNotification() in MainDeployer.deploy() [line 514] down 4 lines after the start() method call. This is because the archive hasn't been expanded yet. I am guessing that when the deployer was re-architected, the number of notifications was cut from 4 to 2. The deployment architecture has undergone major revision, so it isn't really possible to trap after the archive is expanded by AbstractWebContainer.buildWebContext(), but before it is start()ed. This is because the MainDeployer.deploy() calls SubDeployer.start() which calls AbstractWebContainer.start() which calls buildWebContext(). So it all happens in one fell swoop. I believe that the buildWebContext() functionality was originally in an init() method which allowed us to place the notification in between the init() and the start(). From a symmetric point of view the Undeployment notification, occurring within MainDeployer.undeploy(), should probably be moved before the stop(), but if dependent MBean services are removed before the archive is stopped, this could cause problems in redeployment, so perhaps it could be moved between the stop() and the destroy() [line 342]. If the XML files are removed prior to shutdown, it requires the Notification handler to cache any shutdown operations and associate them with archive in a collection. I am open to suggestions. Thank you again. Frederick N. Brier Sr. Software Engineer Multideck Corporation ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Deployment Notifications in JBoss 3.0 changed
You know I read your MBean deployment message back on 10Sep2001, but it didn't really penetrate because we had already added the DeploymentNotification mechanism to 2.4x. I think I could re-engineer my code to fit within the .sar approach. What I called "creating MBeans instances" associated with an archive was one of the things I had implemented on top of the DeploymentNotifcation mechanism, and is exactly what the .sar/-service.xml mechanism does. I wish I had known perhaps we could have worked on it together . I still am figuring out how to participate. The other two things I use it for are loading data for existing MBeans. I could specify MBean instances in the -service.xml file that would have no real interface, but in the start method, find the global MBean and add the data to its dictionary, or in the other way I was using it, execute a series of SQL commands. Do you think it perverse to create MBean classes with no interfaces that just load data for other MBeans? My current mechanism just looks at every archive for a particular name .xml file (for each kind of function) and then processes it. Let me know what you think. Didn't you say if a .sar and EJB were bundles, the MBeans would get processed first? Thank you. Fred Brier At 10:04 PM 4/12/2002, you wrote: >Looks OK to me. I'll check with Andy about the FarmService. Do you need >notifications of each step (there are actually 5 or 6) or are the deploy >and undeploy notifications enough? > >I'm not sure exactly what you are using the notifications for, but I assume >you know about the *-service.xml files and sar files, which let you deploy >sets of mbeans at any time? There is also a dependency mechanism that lets >mbean deployment wait for other mbeans (including ejbs, but right now you >can't make an ejb wait for anything;-). > >david jencks > >On 2002.04.12 20:33:09 -0400 Frederick N. Brier wrote: > > I had submitted some JMX deployment notification code > > (DeploymentNotification class and mods to the J2eeDeployer class) which > > was > > incorporated into JBoss 2.4x. I've just started migrating to JBoss 3.0 > > and > > noticed that the DeploymentInfo object is not passed in the Notification > > anymore, only the url data member is passed to the setUserData() method > > in > > MainDeployer.java. I specifically need the localUrl, but the other info > > was useful as well. This was so that I could open XML files that might > > exist within the deployed archive. The XML files contain SQL commands > > (to > > create additional indexes or load initial data into tables), create > > dynamic > > MBeans instances, and provide configuration data for currently running > > MBeans. > > > > As far as I can tell, changing the parameter of setUserData() to the di > > (DeploymentInfo) from just the URL (di.url) would only effect one line of > > > > code in the distribution. That would be line 459 in > > FarmMemberService.java > > from: > > > > URL lURL = (URL) pNotification.getUserData(); > > > > to: > > > > URL lURL = ((DeploymentInfo)pNotification.getUserData()).url; > > > > The other request is to move the sendNotification() in > > MainDeployer.deploy() [line 514] down 4 lines after the start() method > > call. This is because the archive hasn't been expanded yet. I am > > guessing > > that when the deployer was re-architected, the number of notifications > > was > > cut from 4 to 2. The deployment architecture has undergone major > > revision, > > so it isn't really possible to trap after the archive is expanded by > > AbstractWebContainer.buildWebContext(), but before it is start()ed. This > > > > is because the MainDeployer.deploy() calls SubDeployer.start() which > > calls > > AbstractWebContainer.start() which calls buildWebContext(). So it all > > happens in one fell swoop. I believe that the buildWebContext() > > functionality was originally in an init() method which allowed us to > > place > > the notification in between the init() and the start(). > > > > From a symmetric point of view the Undeployment notification, occurring > > within MainDeployer.undeploy(), should probably be moved before the > > stop(), > > but if dependent MBean services are removed before the archive is > > stopped, > > this could cause problems in redeployment, so perhaps it could be moved > > between the stop() and the destroy() [line 342]. If the XML files are > > removed prior to shutdown, it requires the Notification handler to cache > > any shutdown operations and associa
[JBoss-dev] Bad method call in test code (SecurityConfig.java)
The ./jboss-all/testsuite/build.sh generates a "cannot resolve symbol" error: ./jboss-all/testsuite/src/main/org/jboss/test/security/service/SecurityConfig, Line: 91 config.setConfig(loginConfig); Looks like it should be: config.setConfigURL(loginConfig); After that it builds fine. Thank you. Frederick N. Brier Sr. Software Engineer Multideck Corporation ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss.net idea for Macromedia Flash support
Macromedia Flash 5 and Flash MX has XML support, but due to its limitations cannot generate the exact HTTP headers, specifically SOAPAction, required by SOAP. Flash is installed in over 98% of the browsers and provides a cross platform intelligent (Actionscript) client. In a user group presentation they alluded to a product that would be a Cold Fusion server to Flash client architecture with XML providing the glue. I think JBoss can beat them there with a few small mods to JBoss.net. The idea is to add a doPost() method to the JBoss.net AxisServiceServlet class. It would preprocess the HttpServletRequest headers using a massaging class specified via XML generating a HashMap. It would then wrap the original HttpServletRequest and the HashMap in a class derived from HttpServletRequestWrapper which overrides the getHeader methods. The new request object is passed to the parent's doPost() implementation - AxisServlet. Specifically for Flash, we could appear to move a SOAPAction and Content-Type parameters to the HTTP Header. I've already started writing this and would like to finish it and contribute it. I'm just not sure how to participate in the process, and need some feedback on whether this is desired, acceptable, and if so, where the massaging class should be specified. One issue is that we are violating the SOAP spec, but several products and work-a-rounds already exist, mostly for ASP. Specifying a massaging class allows us to support other hamstrung clients. We could also associate the massaging class with a url-pattern either in install-axis.xml, another extension to the Axis deployment descriptor in the application's web-service.xml file. The changes and additions are fairly small and I could just post them to the mailing list after I get some feedback and get it working. I think this is an important technology with which to interface. With the addition of Flash plug-in's encrypted sandbox, private keys can be stored on the client side and used for authentication in implementing security. Please let me know what you think. Frederick N. Brier Sr. Software Engineer Multideck Corporation ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: [JBoss-dev] JBoss.net idea for Macromedia Flash support
At 10:15 AM 4/17/2002, you wrote: >This is a great idea. Thank you both for the positive feedback. I will try write it up either today or tomorrow. From Dr. Jung's comments, instead of adding a doPost() to AxisServiceServlet and having a separate configurable class to do the massaging, I'll just create a FlashAxisServiceServlet and inherit from AxisServiceServlet and use the existing configuration mechanism. KISS (Keep It Simple Stupid) is better. >The funny thing is I was talking with the Macromedia guys at JavaOne, and >I told them that someone was going to write a patch to hook up flash to >other app servers. They were adamant that people were going to buy their >special flash j2ee bridge, which is very expensive. It's already been done with a tacked on ASP translator. I guess we are going to do it, but with direct support for what Flash can send, JMX manageable and configurable, with J2EE SOAP-to-EJB support, and probably Public/Private Key encryption integrated into Stark's JAAS (I'll need help with that). I've been looking at a few Javascript RSA algorithms that could be embedded into Flash Actionscript classes. Build a few more Actionscript classes to support SOAP Session/Transactions and the security stuff, and it makes a pretty powerful combination. >Also, does any one remember the high quality flash generator server. >-dain $30K, or $1,000 for the off-line version (which I was stupid enough to buy). Unfortunately after my buying the off-line Generator/Flash 4 upgrade the end of last year, they have discontinued the Generator product line. They are supposedly offering an upgrade path to the Cold Fusion server. However, there is another server product that was alluded to that will provide any missing Generator functionality not do-able in Flash MX, but did exist in the "old" Generator product. -Fred. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Old servlet.jar vs. jboss.net/jetty dependency?
I need to use the class javax.servlet.http.HttpServletRequestWrapper for the Flash/Axis servlet, but it can't be found in servlet.jar. Looking closer, I noticed that the build.xml for JBoss.net is referencing a servlet.jar in jboss-all/thirdparty/sun/servlet/lib. The files in the archive are dated 7/11/2000. The actual archive in the JBoss distribution is javax.servlet.jar which is a superset of the older archive, has the current build date, and the required file. The problem is that the javax.servlet.jar is built in the jboss-all/jetty/output/lib directory. So this would require modifying the root build.xml file to make the _module-jboss.net-most dependent on _module-jetty-most, and then modifying the build.xml [lines 91-94] in jboss-all/jboss.net to specify the javax.servlet.jar in the jetty output directory. Is this reasonable? Thank you. Frederick N. Brier Sr. Software Engineer Multideck Corporation ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Multiple Axis Engines, How To?
Dr. Jung, I've been working on Flash being a SOAP client. I didn't realize
how brain dead Macromedia's XML implementation was. There is no namespace
support (it gets confused), no types other than string for which you don't
specify the type, and no validation. However, I still think it will be a
valuable feature.
I believe this can be done by telling the MessageContext to not use
namespace prefixes in the elements of the response. Please correct me if I
am wrong. The code and doc seem to indicate this requires a handler to be
written and then specified in the Axis engine configuration, which is done
in the axis-config.xml file () in the ./server/default/conf
directory. The problem is that the top level element is which
appears to allow only one Axis Engine to be configured. Its name is
"JBoss.net". This file is actually loaded in the class AxisService [line
200-212] creating a AxisServer (engine) class instance into the data member
"axisServer". So it appears that the AxisService which is also the Axis
deployer only supports one engine and thus only one set of handlers.
Looking at the AxisServiceServlet class, it looks like you intended to
allow each ServletContext to specify a different engine [line
40]. However, this would require that each Servlet configuration
(install-axis.xml) to specify an attribute which would be an XML file that
would effectively be the axis-config.xml file (the Axis engine
configuration specifying handlers). As you have already done, if the
AXIS_ENGINE_ATTRIBUTE ("AxisEngine") attribute in the ServletConfig is not
set, the engine is created, and the attribute set with the engine
instance. The axis-config.xml type file would be exist in the jboss-net.sar.
It doesn't seem that it would be additional overhead to have multiple
"engines" which are just chains of handlers. I'm not sure, but it seems
like this change would also allow support of multiple security
configurations. What are your thoughts on this? Thank you again.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] SAR... Sucky ARchive ?
I am afraid I beg to differ. I think that the SAR is an excellent concept and approach. First of all it is simple. Simple is good. Sometimes simple doesn't cover all the bases, but being too complex can make something unusable. In JBoss 2.4x, I had created an alternate solution, but it was more complicated (I'll describe it at the end as an aside). Second, the example you are using with Jetty is a special case of a singleton MBean. In other words there is usually only a single servlet engine running in a JBoss instance. However, in the applications I am building, each deployed application archive is made up of several EJBs with many supporting MBeans. The categories of MBeans are functions such as incrementing keys, pre-populating database tables/tuning with additional SQL commands, and loading non-SQL data into MBeans from XML files contained within the .sar. So even within the same archive, there might be 5 instances of the same MBean class. And there could be many different applications deployed on the same server using the same approach. Here is an alternate idea, something that would co-exist with the .sar concept. Each MBean has a name that makes it unique. Build an XML file with a name space, essentially an element for each MBean that has had its configuration changed from the original .sar archive's jboss-service.xml file. It is basically a Windows Registry. If an MBean's configuration is modified via, say the port 8082 HTML interface, an entry is created if there wasn't one. When an MBean is deployed, the SAR deployer checks the name space. If there is one, the MBean is initialized with those parameters, rather than the ones in the file. Note: only writable properties from the original MBean attributes can be configured. There could even be a "Revert to Defaults" button to switch back to the original values in the .sar. To clear the entire configuration, delete the registry file. But this idea can get complex when we consider versioning. What do you do when a new MBean has or is missing attributes in a previous version? How do you even know it is a different version? Another simpler idea, is to write a tool that opens a .sar, lets you examine the MBean attributes, change them, and re-bundle them. No more pains in the ass, and not very difficult. ASIDE: My JBoss 2.4x approach utilized the MBean Notifications for the J2eeDeployer that I believe David Jencks was kind enough to add to the code base for me. I had an MBean DeploymentManager defined in the jboss.jcml whose sole purpose in life was to register with the J2eeDeployer and listen for new deployments. It then looked in the root of the archive for different named XML files: mbean.xml (the exact same format as David's jboss-service.xml file), an rdbms.xml, and two others. Each was processed by a different handler. Now this isn't that big a deal, but my method required the DeploymentManager to look at every archive to determine whether the special files were present. It also had to play games to figure out if the old temporary hot-deploy directory was sitting around which was the new real one. Finally, I had to write XML parse routines for the mbean.xml file (I would have had to write one for the additional file types anyway). Maybe if the .sar JSR gets modified, maybe we will end up with .jar(s), .war(s), and .ear(s) specifying if a *-service.xml file exists in the root directory or the WEB-INF directory, a deployment manager will process it. But for the time being, .sar deployment is a useful component. Frederick N. Brier Sr. Software Engineer Multideck Corporation At 12:51 AM 4/21/2002, you wrote: >Well, perhaps not completly sucky, but as it is now it does suck. When I >wrote that email long ago about those pesky birds, which eventually lead >to .sar (and other things), I did not have this in mind. > >The idea was to make it *easier* to configuration components not >complicate it. SAR as it is today only complicates... > >Take Jetty for example. I am a user and I want to change the port, or >enable SSL or add a non-deployed webapp for development... how do I do >that? I have to break open the jetty-plugin.sar, change >jboss-service.xml, rejar it, then redeploy. What a huge pain in the ass! > >I think that the concept of a SAR is still useful and we should not cast >it aside, but there are some limited cases where we would use one. > >For example, SAR is good for grouping like .jar's together. There are >several jars needed for Jetty to work, and it makes sence to group them >together inside of a super archive. When used in this manner it makes it >easy to create an explicit classload hierachy (when we have that capability). > >SAR is also good if you want to distribute a set of native libraries. In >this usage you would p
Re: AW: [JBoss-dev] JBoss.net idea for Macromedia Flash support
Sure, I'd like to get feedback. The sooner limitations are seen in a design the better. But it really is going to be relatively simple client side support. I don't want to make the download time too large. I did get side tracked in the last week, but will be writing those Actionscript SOAP classes soon. I'm reorganizing my own project to use the buildmagic approach. One concern I do have is whether if the Actionscript SOAP classes were incorporated into someone's Flash program, would the LGPL would require them to release their source code. That would not be appropriate. It would be bundled as an install-able Flash component, but everything in Flash viewable as source and becomes an .swf file. Fred. At 10:37 AM 5/10/2002, you wrote: >Hello Fred, > I am happy to here that someone will be providing JBoss integration to > Flash MX. I too saw the Macromedia demo at the recent JavaOne and was > blown away by the possibilities. I have been researching every workable > (and FREE) alternative to integrating J2EE server-side apps to a Flash > rich-client front-end. you mentioned having purchased Generator (which is > being phased out at MM) and in case you are not aware of it there is a > free open-source version called JGenerator which was written for Java (do > a search on the web for JGenerator). I use JBoss 2.4.4/Catalina and would > really like to move from Struts client UI to a Flash rich client while > still using J2EE (servlets/ejbs) components. I can't offer technical > assistance but if you need someone to beta test you work I would be happy > to. I am very pleased that the JBoss folks are keeping JBoss in the loop > for what I believe will be a really big paradigm shift in web app development. > >Good job! > >* * * > >View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13125 > >___ > >Have big pipes? SourceForge.net is looking for download mirrors. We supply >the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Castor MBean in a JBoss 3.0 .sar
I've been trying to update some of my app design and code from JBoss
2.4.x to 3.0 and the new .sar approach. I need to specify the
Castor MBean inside a .sar. One issue that I've run into is the
need to convert the relative path of the CastorJDOImpl MBean's
Configuration attribute
("file:./META-INF/database.xml")
to a fully specified, non-relative path (URI). This appears to be a
design limitation of Xerces. So the idea is to use the class loader
for the MBean which should be [???] created to reference the location of
the expanded .sar, no? The following was inserted into the
CastorJDOImpl.java MBean:
URL confUrl =
Thread.currentThread().getContextClassLoader().getResource( _dbConf
);
Where _dbConf is a String containing the Configuration attribute
with a value of
"file:./META-INF/database.xml".
Unfortunately, the resource is never found. getSystemResource()
also does not work. Any suggestions or comments? Help,
please.
As an aside, I found that the castor-jdo-plugin.jar build was commented
out with a note that it needed to be a .sar. That is not
necessarily a requirement. To support independent deployable
application archives that would have different tables and objects they
were mapped to, Castor requires a separate database.xml and mapping.xml
for each one. So the thought is a Castor MBean, along with a
database.xml and mapping.xml file would be bundled in a .sar along with
any EJBs and their respective .jars. The castor-jdo-plugin.jar
would be copied into the jboss/lib directory along with castor.jar.
Then the jboss-service.xml could specify both (as depicted below) to
reference the required archives, and initialize an instance of the
CastorJDOImpl MBean with a different database.xml and mapping.xml for
each. Now I don't know if there are any other weird issues
preventing this, but I looked at the Castor code last year and it seemed
to support multiple databases.
file:META-INF/database.xml
jdo/aiabcommon
1
true
false
false
Oleg Nitz is the author of the Castor MBean, and if he and no one
else minds, and if I can figure out how to get it to work, I'd like to
make the modifications. Any thoughts? Thank you again for the
help.
Fred.
Re: [JBoss-dev] Castor MBean in a JBoss 3.0 .sar
Wow. This could be a major bummer. Castor was only one of several
MBean(s) where I was going to use this technique. I have other MBeans that
also needed to read their own XML files out of the .sar. I was
accomplishing this before (JBoss 2.4.x) with my DeploymentNotification
extension. I am aware of the idea that a .sar might not have any code in
it. But isn't the purpose of the:
XML element to define a ClassLoader for the archive? The MBean was not
loading due to missing classes until all the appropriate .jar(s) were
listed in the above statement. I thought it would be creating a
ClassLoader for the MBean(s) and contained .jar(s). Why would it not add a
classpath to the root directory of where the .sar was expanded? Then any
resources could be loaded out of the archive.
Also, it appears I seemed to have missed a big architectural change. Where
is the directory where the .war(s), .ear(s), etc, are unpacked? Do they no
longer need to be expanded? I thought I saw code in the deployer where
they were still be unzipped? Help!! Because I was
using the Deployment Info to determine the actual temporary directory the
archive was being unpacked in. From that, I was able to find the required
XML resource files for my dynamic MBeans.
Fred.
At 08:44 PM 5/19/2002, you wrote:
>I don't think you are going to be able to use a classloader to try to find
>something in the "same" deployment unit as a mbean config snippet. For
>instance, the mbean could be created in code rather than from a .sar, or
>created in a standalone xml file.
>
>I think you will either have to provide another means of locating the
>database.xml etc such as naming the deployment unit it is in or incorporate
>the contents into your mbean configuration directly as xml element valued
>attributes.
>
>Another possibility might be to make a CastorDeployer that could deploy
>.jar files containing META-INF/database.xml and mapping.xml files.
>
>In a somewhat different direction, Matthew Baird was working on jca-ifying
>the OJB project, and seemed to have gotten pretty far. This might provide
>an alternate deployment mechanism. He had several posts on the jca forum.
>
>david jencks
>
>On 2002.05.19 19:33:34 -0400 Frederick N. Brier wrote:
> > I've been trying to update some of my app design and code from JBoss
> > 2.4.x
> > to 3.0 and the new .sar approach. I need to specify the Castor MBean
> > inside a .sar. One issue that I've run into is the need to convert the
> > relative path of the CastorJDOImpl MBean's Configuration attribute
> > ("file:./META-INF/database.xml") to a fully specified, non-relative path
> > (URI). This appears to be a design limitation of Xerces. So the idea is
> >
> > to use the class loader for the MBean which should be [???] created to
> > reference the location of the expanded .sar, no? The following was
> > inserted into the CastorJDOImpl.java MBean:
> >
> > URL confUrl =
> > Thread.currentThread().getContextClassLoader().getResource( _dbConf );
> >
> > Where _dbConf is a String containing the Configuration attribute with a
> > value of "file:./META-INF/database.xml". Unfortunately, the resource is
> > never found. getSystemResource() also does not work. Any suggestions or
> > comments? Help, please.
> >
> > As an aside, I found that the castor-jdo-plugin.jar build was commented
> > out
> > with a note that it needed to be a .sar. That is not necessarily a
> > requirement. To support independent deployable application archives that
> >
> > would have different tables and objects they were mapped to, Castor
> > requires a separate database.xml and mapping.xml for each one. So the
> > thought is a Castor MBean, along with a database.xml and mapping.xml file
> >
> > would be bundled in a .sar along with any EJBs and their respective
> > .jars. The castor-jdo-plugin.jar would be copied into the jboss/lib
> > directory along with castor.jar. Then the jboss-service.xml could
> > specify
> > both (as depicted below) to reference the required archives, and
> > initialize
> > an instance of the CastorJDOImpl MBean with a different database.xml and
> > mapping.xml for each. Now I don't know if there are any other weird
> > issues
> > preventing this, but I looked at the Castor code last year and it seemed
> > to
> > support multiple databases.
> >
> >
> >
> >
> >
> > > code="org.jboss.jdo.castor.CastorJDOImpl"
> > name="DefaultDomain:service=CastorJDO,name=AIAB-Common">
> > file:META-INF/database.xml
> > jdo/aiabcommon
>
[JBoss-dev] MBean ClassLoader ?revisited?
I just backtracked through the source, and read a bunch of messages of Mark Fleury, Scott Stark, and David Jencks. It sounded like Scott was saying in February (17th) that all the MBean(s) are using the same ClassLoader. But Mark and David were discussing in April ClassLoader(s) per MBean. So I am not sure where this all stands. It looks like the code is in place to allow any MBean to have its own classloader [MBeanServerImpl: invoke(), line 481]. It appears that an MBean ClassLoader must itself be an MBean and registered. If all this is working and I just don't understand how the element works, let me know. On the other hand, David just told me that I can't use a ClassLoader to find a resource. It would appear that all that needs to happen is that the SARDeployer create a ClassLoader MBean based on the DeploymentInfo/Inflated file system location and the element, and insert it at the beginning of the list of MBeans found in the jboss-service.xml file fed to the Service* classes in the org.jboss.system package. Then specify the ClassLoader MBean's ObjectName when invoking the MBeanServer.createMBean() method. The ServiceCreator.install() method actually makes the call to the MBeanServer to create the MBean [line 104-108], but has the parameter for the named ClassLoader commented out. This stuff is very intertwined. And I am not entirely sure that even if I've grasped it, I should attempt to complete the author's intent. But if y'all say go ahead, I'll give it a whirl, unless someone else is willing to step into the breach. Please give me some feedback. Thank you in advance. Fred. ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean ClassLoader ?revisited?
I'd be glad to use the DeploymentInfo if an MBean had access to it. The startService() method has no parameters. The MBean only has access to the primitive values initialized from its XML attributes. So how would the MBean get a hold of it? I do not understand why you feel that having a ClassLoader for the MBean would fail to solve my problem. Shouldn't the ClassLoader, in conjunction with the njar protocol, be able to resolve a relative "file:" protocol address within an archive to a fully explicit "njar:" URL that could be used to create an InputStream [ClassLoader.get*Resource*() methods]. Please explain. And don't worry, I won't be making changes unless a senior developer says go. I am definitely the new kid on the block and nervous about modifying anything. My contribution was going to be to JBoss.net. On the other hand, we have to deliver an application and I'm trying to figure out how to make it work. Fred. At 07:46 AM 5/20/2002, you wrote: >Please do not bring back a classloader/mbean. I don't think it will do >what you want anyway. > >What is wrong with using the DeploymentInfo for the package that has the >info you want in it? DeploymentInfo already has a reference to the >classloader that loads everything in that package. > >david jencks > >On 2002.05.20 01:33:13 -0400 Frederick N. Brier wrote: > > I just backtracked through the source, and read a bunch of messages of > > Mark > > Fleury, Scott Stark, and David Jencks. It sounded like Scott was saying > > in > > February (17th) that all the MBean(s) are using the same ClassLoader. > > But > > Mark and David were discussing in April ClassLoader(s) per MBean. So I > > am > > not sure where this all stands. It looks like the code is in place to > > allow any MBean to have its own classloader [MBeanServerImpl: invoke(), > > line 481]. It appears that an MBean ClassLoader must itself be an MBean > > and registered. If all this is working and I just don't understand how > > the > > element works, let me know. On the other hand, David just > > told > > me that I can't use a ClassLoader to find a resource. > > > > It would appear that all that needs to happen is that the SARDeployer > > create a ClassLoader MBean based on the DeploymentInfo/Inflated file > > system > > location and the element, and insert it at the beginning of > > the > > list of MBeans found in the jboss-service.xml file fed to the Service* > > classes in the org.jboss.system package. Then specify the ClassLoader > > MBean's ObjectName when invoking the MBeanServer.createMBean() method. > > The > > ServiceCreator.install() method actually makes the call to the > > MBeanServer > > to create the MBean [line 104-108], but has the parameter for the named > > ClassLoader commented out. > > > > This stuff is very intertwined. And I am not entirely sure that even if > > I've grasped it, I should attempt to complete the author's intent. But > > if > > y'all say go ahead, I'll give it a whirl, unless someone else is willing > > to > > step into the breach. Please give me some feedback. Thank you in > > advance. > > > > Fred. > > > > > > ___ > > Hundreds of nodes, one monster rendering program. > > Now that's a super model! Visit http://clustering.foundries.sf.net/ > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > >___ >Hundreds of nodes, one monster rendering program. >Now that's a super model! Visit http://clustering.foundries.sf.net/ > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] njar revisited
I was trying to read through the postings regarding njar. It sounded like a lot of work and is an impressive technical achievement, but like Mark, I believe KISS is good. Further, it goes against speed and efficiency. Disk space is cheap. Memory is faster than disk is faster than compressed disk (or unzipping archive files on demand). All the archives (in lib and deploy) on a server are less than 20MB and most are .jar(s). Even with more archives, fully expanded, it is not going to be more than 50MB on machines that have 80+GB drives. Is there some sort of cache mechanism that keeps the njar protocol from repeatedly unzipping the archive to a temporary location each time a InputStream is opened to it? Granted that these things usually only happen at startup, but is it going to happen each time a file is read such as Castor's database.xml and mapping.xml. And there could be multiple MBean(s) in a .sar. Wouldn't that slowdown startup? I am currently concerned about whether a relative file resource can be resolved to a fully expanded URL with the njar: protocol specified. However, even if it can, a second point is many libraries check the protocol of a URL or URI. For example, I am not sure how Xerces would react to nested protocols as required by "njar". The specific classes in question are org.apache.xerces.util.URI and org.apache.xerces.impl.XMLEntityManager's method expandSystemId() [line 1071]. Since Castor is built on top of Xerces, this would cause problems for Castor. I don't know how many other libraries attempt to draw information from a URL, except that the URL exposes methods to decompose it, so that it is a legitimate approach. Further, the java.net.URL class does not seem to provide any methods for understanding nested protocols. Again, if I am missing the boat here, please free to let me have both barrels between the eyes. Fred. ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean ClassLoader ?revisited?
va:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:339) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy3.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:341) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:686) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:522) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:489) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:472) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:318) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:216) at org.jboss.Main.boot(Main.java:148) at org.jboss.Main$1.run(Main.java:381) at java.lang.Thread.run(Thread.java:484) 2002-05-20 20:38:05,347 DEBUG [org.jboss.deployment.SARDeployer] undeploying document file:/usr/local/jboss/server/default/deploy/aiab-common.sar At 12:18 PM 5/20/2002, you wrote: It is still not clear what the structure of the sar that is failing is. Answer that question before we start talking about introducing new class loaders. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Frederick N. Brier" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, May 20, 2002 6:57 AM Subject: Re: [JBoss-dev] MBean ClassLoader ?revisited? > I'd be glad to use the DeploymentInfo if an MBean had access to it. The > startService() method has no parameters. The MBean only has access to the > primitive values initialized from its XML attributes. So how would the > MBean get a hold of it? > > I do not understand why you feel that having a ClassLoader for the MBean > would fail to solve my problem. Shouldn't the ClassLoader, in conjunction > with the njar protocol, be able to resolve a relative "file:" protocol > address within an archive to a fully explicit "njar:" URL that could be > used to create an InputStream [ClassLoader.get*Resource*() > methods]. Please explain. And don't worry, I won't be making changes > unless a senior developer says go. I am definitely the new kid on the > block and nervous about modifying anything. My contribution was going to > be to JBoss.net. On the other hand, we have to deliver an application and > I'm trying to figure out how to make it work. > > Fred. > > At 07:46 AM 5/20/2002, you wrote: > >Please do not bring back a classloader/mbean. I don't think it will do > >what you want anyway. > > > >What is wrong with using the DeploymentInfo for the package that has the > >info you want in it? DeploymentInfo already has a reference to the > >classloader that loads everything in that package. > > > >david jencks ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean ClassLoader ?revisited?
Sorry, it really is uppercase. I verified it with "jar tf aiab-common.sar". The directory it was created from was uppercase. Winzip just showed it as lowercase. Winzip also showed jetty-plugin.sar as using lowercase. But thank you. Fred. At 06:05 PM 5/20/2002, you wrote: >"meta-inf" != "META-INF" > >--jason ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean ClassLoader ?revisited?
You are absolutely correct. Specifying
"file:/" was the
problem. I am SO sorry for bothering you. I've been banging
my head against this for 2 days. I also just verified it works with
both getting the ClassLoader from the CastorJDOImpl class and the thread
context loader. I've read through thousands of lines of JBoss code,
tracing the flow of the SARDeployer, ClassLoader(s), and
MBeanServer. Obviously I wiffed. Thank you for looking into
this Scott, and my apologies again for wasting your, David's, and Jason's
time.
Fred.
P.S.: I need to write some tests, but if they work, would it be
acceptable to update the CastorJDOImpl MBean to resolve the specified
Configuration attribute to the expanded URL? Again, thank
you.
At 11:32 PM 5/20/2002, you wrote:
Using a resource
name of
"file:/META-INF/database.xml"
does not make sense
as this is asking for the file located at the
absolute path /META-INF/database.xml.
I created a test of loading a resource from a
service start and parsing the resulting
xml doc using a contruct like:
URL url0 =
loader.getResource("META-INF/config.xml");
if( url0 != null )
{
InputStream is =
url0.openStream();
SAXParserFactory factory
= SAXParserFactory.newInstance();
SAXParser parser =
factory.newSAXParser();
parser.parse(is, new
DefaultHandler());
log.debug("Successfully parsed url0");
is.close();
}
where loader could be either the service class
ClassLoader or the thread
context ClassLoader. I did find a problem when
multiple services are included
in a deployment and use the same config file
name even though it is located
in distinct paths. See Bug #558525 for more
info on that but this not the
issue you are seeing with the
FileNotFoundException.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxx
- Original Message -
From: Frederick N.
Brier
To:
[EMAIL PROTECTED]
Sent: Monday, May 20, 2002 2:50 PM
Subject: Re: [JBoss-dev] MBean ClassLoader ?revisited?
Not a problem. Hopefully this email will contain the requested info. BTW, I'm not even sure I was asking for a new ClassLoader. I saw a significant amount of code in MBeanServerImpl.invoke() and ServiceCreator.install() that seemed to imply that the intention was to have a ClassLoader for each deployed SAR. This made sense considering the issues I think I am running into. Although the below SAR info is for the Castor MBean, I also have several MBean(s) I have been writing to convert from my DeploymentNotification approach under JBoss 2.4.x. The problem is being able to read configuration files from the startService() method of an MBean such as CastorJDOImpl.java (in the varia module). My aiab-common.sar has the following files in it:
aiab-common.jar
castor-jdo-plugin.jar <---including this file or putting in in jboss/lib makes no difference.
meta-inf/jboss-service.xml
meta-inf/Manifest.mf
meta-inf/database.xml
meta-inf/mapping.xml
The jboss-service.xml file is:
[JBoss-dev] Task#51309, Xdoclet2WebService
How do I get assigned a task? I'm trying to take a swag at #51309. Thank you. Fred. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Need to create service with its UCL
I think it is a good idea. I vote for it. There were some notes in one my emails on the 20th with a suggested approach. On the DeploymentInfo, I think David is correct about eventually wanting the DeploymentInfo as an MBean. A friend of mine comparing Weblogic and JBoss, was miffed at the lack of a pretty interface for showing all the deployed applications. On the UI issue, Jason is also correct. Eventually we will have to make the JMBean interface more usable. For now, I don't think there will be that many and we could stick them in a separate "Domain" so they are "off to the side". I have some ideas for using a tree control for the UI which I can put in a separate email. Fred. At 10:10 PM 5/23/2002, you wrote: >Right now services have no mechanism to uniquely load resources >located in their sar because the UCL of the sar is not specified >as the loader in the JMX createMBean call. To do this the UCLs >would have to be made MBeans as that is what is required by >the createMBean call signature. It seems like an unnecessary >number of mbeans, but only the service UCLs would actually >need to be registered. Any feedback before I do this? > > >Scott Stark >Chief Technology Officer >JBoss Group, LLC > > > >___ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] MBean viewer ideas
This is in regards to the MBean viewer on port 8082. Instead of using an HTML interface, what if we made it a SOAP interface with a Java Client? This could tie into JAAS security and limit access. I wrote a similar GUI on another Java project. I don't want to cause anyone nausea, but the UI was similar to Microsoft Management Console (MMC). Further, the MBean or SessionBean that was acting as the SOAP service could act as a broker for the same SOAP service running on every JBoss server in the cluster. For those not familiar with it, the MMC has a tree control in a pane to the left and the right pane is defined based on the tree node selected on the left side. The tree child nodes at each level are configurable, both by attributes such as "hostname", "domain"(JMX), "service", "name", and "type" or fixed expressions or value lists. So the default which would look similar to now would be by "domain" name attribute which would yield nodes such as "DefaultDomain", "JMImplementation", or "jboss.deployment". You could also have multiple configurations to look at your beans differently. For instance, if you had an MBean showing number of transactions per second, the tree could show that MBean service at the top node and then all the hostnames underneath it. So you could easily flick from node to note looking for bottlenecks. Of course, with all of the data as XML, you easily design new node/panel "handlers" that could display charts, graphs, aggregate tables of performance data, etc. One could even have the GUI plug into the MMC and become part of the standard Microsoft operating environment . We could also have the nodes extend into the attributes of an MBean. For instance, the Jetty MBean has a DeployedApplications attribute which is a java.util.Iterator which can't be displayed. Wouldn't it be nice to be able to have a table possibly with hyper-links to related MBeans? Another idea is how to provide better context help for the MBean viewer. This idea uses XDoclet to generate an XML file that could be bundled in the .jar containing the class files for the MBean. It would strip the JavaDoc from the class and data members from the MBean class. Instead of having a dialog pop up and say "MBean Attribute" you have a description of what it is, as well as the MBean itself. This information would be retrieved by the MBean Viewer SOAP service and provided to the GUI. Thoughts? Frederick N. Brier Sr. Software Engineer Multideck Corporation ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Need to create service with its UCL
I was trying to back track and read the messages on jsr-77. My apologies, I had never heard of it, so I am playing catch up. There seems to be a never ending stream of APIs. I just skimmed the JavaOne Presentation 1717 and looked at the http://java.sun.com/j2ee/tools/management/ web page for the reference implementation. Was Sun writing the GUI or was Andreas? What is Emma? Fred. At 11:47 AM 5/24/2002, you wrote: >How about jsr-77? > >david jencks ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MBean viewer ideas
Thank you. I didn't know about the jsr-77 stuff though. So first I'll review its features and design, and see what the architects think of the ideas. I might not get involved in that until after July, but I am interested in creating a management console. My first focus is first on the JBoss.net. Then there are a few other ideas that my application might require. One is support for replicated database servers such as those provided by mysql. I haven't seen anything in the docs about it. My thought is to enhance the JDBC connection pool MBean (Minerva?). It would list each slave as well as the master in the JDBC connection pool MBean. If the Master fails, you lose contact, can't ping it, etc, the pool is flushed and connections are created for the next slave in the list, possibly executing some code that would let the slave SQL server know it is now the master. The data source stays the same, and applications are none the wiser. I've never done mysql replication, and it is apparently a new and growing mysql feature, but I don't want to spring for an Oracle license if I don't have to. Fred. At 10:25 PM 5/24/2002, you wrote: >Hi. Some interesting ideas. I do not think we can or should drop the HTML >interface. It is very handy for administration on machines where you can not >install a Java client app. > >I don't want to stop you from creating a SOAP adapter to JMX, which is >what is >sounds like you want to build... go for it. But we can't replace the HTML >adapter with it, though we should replace it with something better at some >point... that thing sucks. > >--jason ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] or MBean
I'm not sure this is related to what you are talking about, but I've
modified CastorJDOImpl.java. I haven't committed it, because I
haven't fully tested it yet. It executes which seems to indicate
that the database.xml and the mapping.xml were loaded, but I haven't
tried to write to the database using the mapping.xml data that was read
in. The bulk of the few small changes are as follows [startService,
line 122]:
// Determine complete URL to _dbConf
file. It is likely a relative path.
URL confUrl
= Thread.currentThread().getContextClassLoader().getResource( _dbConf
);
if ( null == confUrl )
{
FileNotFoundException e = new FileNotFoundException(
"CastorJDOImpl.startService(): Unable
to resolve Configuration attribute to URL = "
+ _dbConf );
log.error( "CastorJDOImpl.startService(): Unable to
find " + _dbConf + " file.", e );
}
_dbUrl = confUrl.toString();
_jdo.setTransactionManager("java:/TransactionManager");
_jdo.setConfiguration( _dbUrl );
unm = new Unmarshaller(org.exolab.castor.jdo.conf.Database.class);
database = (org.exolab.castor.jdo.conf.Database) unm.unmarshal(new
InputSource( _dbUrl ));
and this attribute accessor method:
public String
getConfigurationURL() {
return _dbUrl;
}
Is that what you are talking about? If so, let me know and I
will commit it. Thanks.
Fred.
At 01:25 AM 5/31/2002, you wrote:
I have looked into replacing the metadata xml
parsing with Castor XML in my
spare time (ha, spare time... I made a joke). From a few emails
with the
Castor folks I belive that the XML snippet is possible with Castor
because it
is based on XML Schema's and not DTD... but I have not tested anything
yet.
Once I have verified that this will work, I will setup a prototype for
the
service configuration. This should allow us to easily modify the
ServiceController and friends to allow better register/create/start
control.
--jason
[JBoss-dev] Potential .jar problem in all build.xml(s)
In attempting to use a modified xdoclet.jar local to a sub-project
(jboss.net) so we could slowly develop new XDoclet templates and later
submit them, I discovered that the "ant" shell script in
./tools/bin is generating a classpath that is including all of the
.jar(s) in ./tools/lib. It was pre-empting path-wise, the path I
was specifying in my build script.
So even though there is all this code in all the build scripts specifying
the junit.jar in ./thirdparty/junit/junit/lib, the junit.jar actually
getting used is in ./tools/lib. There are classes overlapping in
./thirdparty/apache/log4j/lib/log4j.jar and
./tools/lib/log4j-core.jar. In the jmx sub-project build.xml,
sax2.jar and sax2-ext.jar, located in ./thirdparty/xml/sax/lib are used
which have overlapping classes with crimson.jar in ./tools/lib.
Further, there additional copies of crimson.jar, jaxp.jar, and xalan.jar
in both ./tools/lib and ./thirdparty/sun/jaxp with different dates and
sizes. These files are referenced in the top level build.xml.
There is a duplicate bsf.jar in the ./thirdparty/ibm/bsf/lib, but it
doesn't seem to be used anywhere.
If this really is a problem, several of us could be banging our head
against the wall trying to solve a bug in an old .jar. Perhaps we
should remove any .jar that appears in the thirdparty directory from
./tools/lib, and only keep Ant required files there. I would like
the xdoclet .jars moved into the thirdparty. That way, as we develop new
xdoclet templates for generating deployment descriptors and code
generators, we can evolve them, before submitting them to be
included in the XDoclet codebase. The relevant shell script was in
./tools/bin/ant:
# add in the dependency .jar files
DIRLIBS=${ANT_HOME}/lib/*.jar
for i in ${DIRLIBS}
do
# if the directory is empty, then it will return the
input string
# this is stupid, so case for it
if [ "$i" != "${DIRLIBS}" ] ;
then
if [ -z "$LOCALCLASSPATH" ] ;
then
LOCALCLASSPATH=$i
else
LOCALCLASSPATH="$i":$LOCALCLASSPATH
fi
fi
done
Frederick N. Brier
Sr. Software Engineer
Multideck Corporation
[JBoss-dev] Re: [Xdoclet-user] Weird appearing "X" problem
I think I've tracked the problem down. The version of xdoclet.jar that is in the JBoss 3.0 CVS tree has a bug in it. Unzipping the .jar and looking at the binaries, both of the TLD_PUBLICID constants for 1.1 and 1.2 in JspTaglibSubTask.class both say "XTag". Very bizarre. I will update the .jar in CVS. The final XDoclet 1.1.2 release that I snagged out of the XDoclet CVS did not have the bug. Thanks. Fred. At 09:21 PM 6/2/2002, you wrote: >I have been trying to track down a problem, but feel like I am in the >twilight zone. The line below says "DTD JSP XTag Library" instead of "DTD >JSP Tag Library", I have no idea where the "X" is coming from. > >1.2//EN" "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd";> > >The JspTaglibSubTask.java file clearly says: > >private static String TLD_PUBLICID_1_2 = "-//Sun Microsystems, Inc.//DTD >JSP Tag Library 1.2//EN"; > >So where could the "XTag" be coming from. I've run the build a couple of >times. The files are not getting filtered. They are generated to a >destination directory and not moved. Any ideas? Anyone seen anything >weird like this before? > > > > >___ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >___ >Xdoclet-user mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/xdoclet-user ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] New XDoclet provides modular addition of subtasks
One of the XDoclet developers, Pazu, said they just finished a refactoring that allows the addition of new sub tasks merely by copying them into the lib directory. If either David or Aslak, or whom ever has needed customization of XDoclet could transition to the new revision, we can just use the canned XDoclet from now on. Does that sound good? Fred. >Em Seg, 2002-06-03 às 11:29, Frederick N. Brier escreveu: > > > Ideally, it > > would be nice if XDoclet utilized an external XML file and additional > > subtasks could be seamlessly integrated without having to modify > > EjbDocletTask.java or having to do a separate XDoclet Ant task. > >We just finished a big refactory that does that and a bit more. Now you >can write xdoclet modules and just drop them on the lib dir and the >doclet task will load them up :) > >Get the source, look at the existing modules, write more of them! > >-- >Pazu <[EMAIL PROTECTED]> > >Anime Gaiden - De fãs para fãs, sempre. >http://www.animegaiden.com.br -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8+7BQlkXX37ZlscIRAqHUAJ9xEX1m7B69aCsb5tGhVYcE6w1atwCfVkIO VpjSE4vNmyFVI5Nj8hoaFNk= =tRiz -END PGP SIGNATURE-
[JBoss-dev] RE: [Xdoclet-user] Weird appearing "X" problem
Perhaps we ought to put a vendor branch of the XDoclet source (at a release) in the thirdparty subdirectory? Then any developer could make mods and rebuild without worrying about stepping on someone else's changes or losing code. When XDoclet makes a new release we merge with our non-vendor branch code. And if Ara wants to incorporate code from the branch back into the XDoclet project, he can pick and choose. Ideally, it would be nice if XDoclet utilized an external XML file and additional subtasks could be seamlessly integrated without having to modify EjbDocletTask.java or having to do a separate XDoclet Ant task. What do y'all think? :) Fred. At 04:13 AM 6/3/2002, Aslak Hellesøy wrote: >Well, the problem reported by Frederick was still in our CVS code > >private static String TLD_PUBLICID_1_2 = "-//Sun Microsystems, Inc.//DTD JSP >XTag Library 1.2//EN"; > >This is probably due to some over-eager search-replace operation I did a >while ago when refactoring to xjavadoc. > >It's fixed now and committed to CVS. > >Thanks for pointing it out. > >Aslak > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of David > > Jencks > > Sent: 3. juni 2002 04:36 > > To: Frederick N . Brier > > Cc: [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: Re: [Xdoclet-user] Weird appearing "X" problem > > > > > > Please be careful. IIRC, the jboss xdoclet version is tagged in xdoclet > > source and is ___AFTER___ 1.1.2, and it includes some > > functionality I added > > not in 1.1.2 that is used in the build. > > > > Please try with the cvs version of xdoclet. If it works I can tag the > > xdoclet source and get a reproducible version in jboss. > > > > > > Be sure to do a clean build and run the testsuite before changing the > > xdoclet version. > > > > thanks > > david jencks > > > > On 2002.06.02 22:15:19 -0400 Frederick N. Brier wrote: > > > I think I've tracked the problem down. The version of xdoclet.jar that > > > is > > > in the JBoss 3.0 CVS tree has a bug in it. Unzipping the .jar and > > > looking > > > at the binaries, both of the TLD_PUBLICID constants for 1.1 and 1.2 in > > > JspTaglibSubTask.class both say "XTag". Very bizarre. I will > > update the > > > > > > .jar in CVS. The final XDoclet 1.1.2 release that I snagged out of the > > > XDoclet CVS did not have the bug. Thanks. > > > > > > Fred. > > > > > > At 09:21 PM 6/2/2002, you wrote: > > > >I have been trying to track down a problem, but feel like I am in the > > > >twilight zone. The line below says "DTD JSP XTag Library" instead of > > > "DTD > > > >JSP Tag Library", I have no idea where the "X" is coming from. > > > > > > > > > XTag Library > > > > > > >1.2//EN" "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd";> > > > > > > > >The JspTaglibSubTask.java file clearly says: > > > > > > > >private static String TLD_PUBLICID_1_2 = "-//Sun Microsystems, > > Inc.//DTD > > > > > > >JSP Tag Library 1.2//EN"; > > > > > > > >So where could the "XTag" be coming from. I've run the build a couple > > > of > > > >times. The files are not getting filtered. They are generated to a > > > >destination directory and not moved. Any ideas? Anyone seen anything > > > >weird like this before? > > > > > > > > > > > > > > > > > > > >___ > > > > > > > >Don't miss the 2002 Sprint PCS Application Developer's Conference > > > >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > > > > >___ > > > >Xdoclet-user mailing list > > > >[EMAIL PROTECTED] > > > >https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > > > > > > > > ___ > > > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > > > ___ > > > Xdoclet-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > > > > > > > > > ___ > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > ___ > > Xdoclet-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/xdoclet-user ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] New XDoclet provides modular addition of subtasks
David, I might be able to take a stab and moving to the latest XDoclet. However, it also requires the new Ant 1.5 beta. Would it be ok to migrate JBoss to use the new Ant as well? Also do you have copies of the source used to modify the XDoclet jar in ./tools/lib? I was also thinking of removing the duplicate .jar(s) from the ./tools/lib directory at the same time and make sure we are using the latest stable versions of the third party libraries as well. I will run all the tests to make sure it passes all the same tests as before I made the changes. Thanks. Fred. At 03:56 PM 6/3/2002, David Jencks wrote: >Do you personally have enough time to see if the jboss build works with the >current xdoclet cvs version? I would like to make sure jboss 3 works well >with current xdoclet before the xdoclet 1.2 release, but am pressed for >time right now. If you can verify that at least jboss 3.1 builds and the >testsuite runs with no more errors I will tag the xdoclet sources and put >that version of xdoclet in the jboss tree. If it doesn't work we should at >least tell the xdoclet folks and preferably fix it. > > >Thanks >david jencks > > >On 2002.06.03 14:39:13 -0400 Frederick N. Brier wrote: > > One of the XDoclet developers, Pazu, said they just finished a > > refactoring > > that allows the addition of new sub tasks merely by copying them into the > > > > lib directory. If either David or Aslak, or whom ever has needed > > customization of XDoclet could transition to the new revision, we can > > just > > use the canned XDoclet from now on. Does that sound good? > > > > Fred. > > > > >Em Seg, 2002-06-03 às 11:29, Frederick N. Brier escreveu: > > > > > > > Ideally, it > > > > would be nice if XDoclet utilized an external XML file and additional > > > > subtasks could be seamlessly integrated without having to modify > > > > EjbDocletTask.java or having to do a separate XDoclet Ant task. > > > > > >We just finished a big refactory that does that and a bit more. Now you > > >can write xdoclet modules and just drop them on the lib dir and the > > >doclet task will load them up :) > > > > > >Get the source, look at the existing modules, write more of them! > > > > > >-- > > >Pazu <[EMAIL PROTECTED]> > > > > > >Anime Gaiden - De fãs para fãs, sempre. > > >http://www.animegaiden.com.br > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1.0.6 (GNU/Linux) > > Comment: For info see http://www.gnupg.org > > > > iD8DBQA8+7BQlkXX37ZlscIRAqHUAJ9xEX1m7B69aCsb5tGhVYcE6w1atwCfVkIO > > VpjSE4vNmyFVI5Nj8hoaFNk= > > =tRiz > > -END PGP SIGNATURE- > > > >___ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Test Suite procedure
I ran the tests as per the instructions on http://lubega.com however my invocation of build run-basic-testsuite only generated 658 tests, with 228 successful, 418 errors, and 12 failures. I did a CVS update right after I got Chris's message. What am I doing wrong? That is a lot of errors. I am using the JDK1.4.0_01, and I noticed he was testing with JDK1.3.1 for that test. Different JDKs and platforms generated different numbers of tests and errors. Is there an explanation of why and what tests kick in for what platforms? Should I switch back to JDK1.3? Does the JDK1.4 always generate that many errors? Thanks. Fred. At 09:44 PM 6/13/2002, [EMAIL PROTECTED] wrote: >Number of tests run: 772 > >Successful tests: 763 >Errors:6 >Failures: 3 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Test Suite procedure
I ran the tests as per the instructions on http://lubega.com however my invocation of build run-basic-testsuite only generated 658 tests, with 228 successful, 418 errors, and 12 failures. I did a CVS update right after I got Chris's message. What am I doing wrong? That is a lot of errors. I am using the JDK1.4.0_01, and I noticed he was testing with JDK1.3.1 for that test. Different JDKs and platforms generated different numbers of tests and errors. Is there an explanation of why and what tests kick in for what platforms? Should I switch back to JDK1.3? Does the JDK1.4 always generate that many errors? Thanks. Fred. At 09:44 PM 6/13/2002, [EMAIL PROTECTED] wrote: >Number of tests run: 772 > >Successful tests: 763 >Errors:6 >Failures: 3 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Dreamweaver MX: njar vs. expanded directories?
Let us say you are using a tool like Macromedia Dreamweaver UltraDev/MX and their LiveUpdate feature. This is where you are using a wysiwyg HTML/JSP editor and you can click a button, it uploads a temporary version of the file to the server, it invokes the JSP generating the page, gets the results, correlates the generated page to the original JSP, and displays as a web page. You can fill in data, press buttons, follow hyperlinks etc. You are working with a live page. Very cool and useful. But you have to be able to copy/ftp the JSP to a real directory. Now it was a mildly annoying, under JBoss 2.4.x, that with the hot deploy the temporary directory name could keep changing because Dreamweaver didn't know how to deal with it, but it worked. So the question is, how do I do that now with the .war appearing to be bundled up? Where would I copy the JSP? Fred. --- 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] Dreamweaver MX: njar vs. expanded directories?
Sorry Jules, I wasn't sure where to post it. But I was posting this more as a design discussion and a continuation of an earlier post about the njar protocol and whether it was really a good idea. Not that it isn't slick piece of encapsulation. I will try your recommendation and copy the .jsp into the my.war directory. As far as the tool, Ultradev/Drumbeat/MX, I believe its Live Data feature predates the use of .war(s) to bundle .jsp(s) and servlets. But even that isn't the issue. Easy to use GUI tools lower development costs. Just because the spec says we are allowed to hide how we access an archive, doesn't mean its a good idea not to provide an "interface" by which development tools can interact with the container. If the above approach doesn't work, maybe we need to design one that does. If it does, we should document it and submit as a standard. Fred. At 05:29 PM 6/30/2002, Jules Gosnell wrote: >This should really be posted to jboss-user or the forums - jboss-dev is >for discussion amongst developers of (not 'on') JBoss. > >It's a BAD idea for any tool to be second guessing where a WebContainer >will be unpacking it's wars - because the spec does not say anything about >it. In fact the WebContainer may just run them packed. > >If your tool will only work with unpacked dirs - then deploy your war >unpacked (a dir hierarchy called e.g. my.war that mirrors the packed >tree), and write your files back into this. I THINK that Jasper will spot >the changes and react accordingly. > > >Jules > > >Frederick N. Brier wrote: >>Let us say you are using a tool like Macromedia Dreamweaver UltraDev/MX >>and their LiveUpdate feature. This is where you are using a wysiwyg >>HTML/JSP editor and you can click a button, it uploads a temporary >>version of the file to the server, it invokes the JSP generating the >>page, gets the results, correlates the generated page to the original >>JSP, and displays as a web page. You can fill in data, press buttons, >>follow hyperlinks etc. You are working with a live page. Very cool and >>useful. But you have to be able to copy/ftp the JSP to a real directory. >>Now it was a mildly annoying, under JBoss 2.4.x, that with the hot deploy >>the temporary directory name could keep changing because Dreamweaver >>didn't know how to deal with it, but it worked. So the question is, how >>do I do that now with the .war appearing to be bundled up? Where would I >>copy the JSP? >>Fred. >> >>--- >>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] WebSite JSP precompilation.... - need XML Help !
I think its asking for a document header and DTD specification. Problem is there is no parent XML element () enclosing multiple XML elements ( and servlet-mapping>). So that won't work. What if you just programmatically merge them into your web.xml? It sounds like you know where the insertion point is. If another code module is generating the web.xml, use a marker that isn't valid XML like <>. Fred. At 09:59 AM 7/1/2002, you wrote: >I checked out the website module to see if I could fix the build.xml to >precompile all the JSP pages. > >I'm nearly there, but my XML skills are letting me down... > >I can get Jasper to compile all the JSPs into Java >I can compile these into classes. > >The problem then is that Jasper helpfully generates me an xml snippet >containing some and directives. This needs >to be inserted into the web.xml at the correct place. Jasper is then >effectively removed from the equation as all mappings are directed >straight to precompiled java servlets, instead of through Jasper. > >I am trying something like: > >]> > >at the top of the web.xml amd then : > >&jsp_mappings; > >where I want the snippet inserted... (jsp_mappings.xml is in WEB-INF with >web.xml) > >No dice : > >14:28:44,992 ERROR [XmlFileLoader] Relative URI "jsp_mappings.xml"; can >not be resolved without a document URI.:-1:2 >org.xml.sax.SAXParseException: Relative URI "jsp_mappings.xml"; can not be >resolved without a document URI. > at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) > at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3102) > at > >Does this mean that I need to have some sort of custom resolver registered ? > >All I want to do is #include a piece of xml into an xml file - is there a >better way > >Thanks all, > > >Jules > > > >--- >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] WebSite JSP precompilation.... Misread. Try[2]
Are you using XDoclet? Because there is an insertion point in XDoclet if you specify the servlets.xml file directory in the mergeDir attribute. Then just rename the Jasper generated file servlets.xml. Is that what you are doing? Fred. At 09:59 AM 7/1/2002, you wrote: >I checked out the website module to see if I could fix the build.xml to >precompile all the JSP pages. > >I'm nearly there, but my XML skills are letting me down... > >I can get Jasper to compile all the JSPs into Java >I can compile these into classes. > >The problem then is that Jasper helpfully generates me an xml snippet >containing some and directives. This needs >to be inserted into the web.xml at the correct place. Jasper is then >effectively removed from the equation as all mappings are directed >straight to precompiled java servlets, instead of through Jasper. > >I am trying something like: > >]> > >at the top of the web.xml amd then : > >&jsp_mappings; > >where I want the snippet inserted... (jsp_mappings.xml is in WEB-INF with >web.xml) > >No dice : > >14:28:44,992 ERROR [XmlFileLoader] Relative URI "jsp_mappings.xml"; can >not be resolved without a document URI.:-1:2 >org.xml.sax.SAXParseException: Relative URI "jsp_mappings.xml"; can not be >resolved without a document URI. > at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3108) > at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3102) > at > >Does this mean that I need to have some sort of custom resolver registered ? > >All I want to do is #include a piece of xml into an xml file - is there a >better way > >Thanks all, > > >Jules > > > >--- >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] AW: jboss 4 build system changes, possible jboss.net and catalina impact.
Yes, jboss.net's build.xml points to an xdoclet version based on the official xdoclet 1.1.2 with the addition of the web-service.xml generation. The source's modification is checked in under thirdparty. The global xdoclet version is the modified version that I believe David or someone else created. If I remember correctly, they indicated that it was a version between 1.1.2 and the current XDoclet, but before their large refactoring effort. It is my intention since Ara informed me that a couple of bugs were fixed that had prevented messaging (nested classes) from building, and memory issues, to test building our latest with their latest. Fred. At 02:33 AM 9/11/2002, Jung , Dr. Christoph wrote: >David, > >Thanks for the notice. > >Unfortunately, I have no exact idea about the differences of the >jboss-xdoclet and the version that Frederick was getting by the xdoclet guys >(must have been something between 1.1 and 1.2 with some bugs fixed?). >Frederick, could you please synchronize with David on the global xdoclet >version? > >AFAIK, xdoclet only affects the flash sample and not the testsuite (which >did run fine with Jetty on Monday, so I´ll test it again). > >I guess that we won´t backport the build changes to 3.2? I´m going to >migrate the latest jboss.net status into 3.2 this week, so I´d have to be a >bit careful about what to sync and what not ... > >Do you have any cvs tricks for back-integration? I´m very used to the >comfortable perforce integration feature, but I guess that I need to compare >the absolute branches with diff here, right? > >CGJ > > > >-Ursprüngliche Nachricht- >Von: David Jencks [mailto:[EMAIL PROTECTED]] >Gesendet: Mittwoch, 11. September 2002 00:15 >An: Jung Christoph; jboss-dev >Cc: Bruce Scharlau >Betreff: jboss 4 build system changes, possible jboss.net and catalina >impact. > > >I replaced many of the repetitive elements in the build.xml files with >parameter entities, including the definition of xdoclet tasks. As far as I >can tell this hasn't affected anything according to the testsuite. > >However, one effect is that xdoclet is now always the "global" xdoclet in >thirdparty. Previously it looks like a local version was being used in >jboss.net. I don't know if there are any tests of jboss.net: the module >appears to compile fine. > >If this has broken something let me know. I'd prefer to fix it in xdoclet >if possible since the xdoclet 1.2 release is imminent. > > > >I also don't know if the catalina module still works and don't know how to >test it. I only partially converted that build.xml, leaving the previous >definitions commented out. Again, info appreciated. > >thanks >david jencks >### > >This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. >For more information, connect to http://www.F-Secure.com/ > > >--- >In remembrance >www.osdn.com/911/ >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
