[JBoss-user] Question on how to deploy multiple ear file of the same application
Hi, I have an application implementing servlet-SLSB-EB that runs well on jboss3.0.4. My problem is how to duplicate this same application several times that will run on the same machine/jboss/web/database server instance (to be consumed by different customers much like an App Service Provider model). So far what I did is to build an ear file for each application instance with a different JNDI name, url name, and database instance. Is this a correct approach? However, doing this approach I encountered a problem with associating a particular application instance with a new datasource. What I did is I created a new -service.xml with a new datasource name and then I modified the jbosscmp-jdbc.xml to use the new datasource name. Is this correct, or did I missed something? thanks! Rene --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Help request: Deploying separated EJB and Web containers
I did something similar. The difference is that I don´t have any authentication on Tomcat. I wrote a Tomcat Valve that is responsible for passing the user and password to JBoss, using a ClientLoginModule. The major drawback in this approach is that the Valve is invoked everytime a sevlet or JSP is called, so the same information is sent to JBoss a lot of times. Hope it helps. Mauricio ___ Busca Yahoo! O melhor lugar para encontrar tudo o que você procura na Internet http://br.busca.yahoo.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] CounterService MBean
Hi, happy new year :) Can anyone please shed some light on for what the CounterService MBean is for exactly and how it is used to measure performance bottlenecks. Thanks! Cheers, Bernhard Bernhard Meyer-Willner, MSc Insurance - Financial Services _ LogicaCMG Logica GmbH Osterbekstrasse 90b - Alster City 22083 Hamburg Germany T: +49 (0) 40 27071-405 (direct) M: +49 (0) 177 425-9036 E: [EMAIL PROTECTED] www.logicacmg.com This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
[JBoss-user] Re: HELP - JBoss 3.0.4/Oracle TopLink 9.0.3/JTS/Oracle (XADataSource/DataSource) - Followup Info
I made some progress today. My problem with Transactions was a simple one from a Oracle DataSource Standpoint. In WebLogic you do not have to set the TransactionManager using the TopLink JTSSynchronizationListener, but in JBoss you do. So the following code fixed the problem with exception using the Oracle DataSource: javax.transaction.TransactionManager tm = (TransactionManager)JNDIHelper.lookup(java:/TransactionManager); JTSSynchronizationListener.setTransactionManager(tm); I still cannot get Oracle XA DataSources to work. I am still getting the XAER_RMERR I mentioned in my first email. I believe it is that the initxa.sql/initjvm.sql script has not been run in the database. But if anyone has other ideas on the Oracle XA DataSource that would be great thanks. By the way I also found out the problem with TopLink JNDIConnector and InvalidNamingException not a CompoundName. It is not a compound name, TopLink's JNDIConnector returns a CompositeName which JBoss does not handle. After looking through the JBoss 3.0.4 code I noticed that it only seems to support CompoundName. Can anyone confirm that? Thanks Mike H. Sr. Mike H. Sr. Michael Huneycutt Sr. TRC - A perotsystems* Company Email: [EMAIL PROTECTED] Office FL: (813) 891-6084 x47395 Office VA: (804) 934-0977 Cell: (804) 304-7655 URL: www.trcinc.com www.perotsys.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] CompositeName and JBoss 3.0.4
After looking at the JBoss code, it appears that JBoss only supports Compound Names and not Composite Names. I have something I am trying to hook up (TopLink), which uses Composite Names. I have no control over this, I found a work around, by I was looking for help in understanding why only Compound Name support and is there a JBoss solution. For more detail look at my post on TopLink in this forum. Thanks Mike H. Sr. Michael Huneycutt Sr. TRC - A perotsystems* Company Email: [EMAIL PROTECTED] Office FL: (813) 891-6084 x47395 Office VA: (804) 934-0977 Cell: (804) 304-7655 URL: www.trcinc.com www.perotsys.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Store large pdfs with JBoss
Has anyone had experience storing large pdfs with jboss, say ~5mbs each? I would like to do it with Oracle and BLOBs, but i've read that there's problems with the drivers and jboss and it doesn't look like it will be possible. Has anyone done with with any other database? Does anyone have ideas on how else to store these files, maybe without a database? I've always thought the filesystem was pretty much off limits from the appserver. thanks. .peter This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information constitute our judgment as of this date and are subject to change without notice. Any information you share with us will be used in the operation of our business, and we do not request and do not want any material, nonpublic information. Absent an express prior written agreement, we are not agreeing to treat any information confidentially and will use any and all information and reserve the right to publish or disclose any information you share with us.
RE: [JBoss-user] Store large pdfs with JBoss
I've always done it with the filesystem. The database just stores the path to the file. Typically you establish some rules for the filesystem store (retention time, max space, maybe use quotas) and have it owned by whatever user the app server runs as. -Original Message-From: Luttrell, Peter [mailto:[EMAIL PROTECTED]]Sent: Friday, January 03, 2003 09:14To: [EMAIL PROTECTED]Subject: [JBoss-user] Store large pdfs with JBoss Has anyone had experience storing large pdfs with jboss, say ~5mbs each? I would like to do it with Oracle and BLOBs, but i've read that there's problems with the drivers and jboss and it doesn't look like it will be possible. Has anyone done with with any other database? Does anyone have ideas on how else to store these files, maybe without a database? I've always thought the filesystem was pretty much off limits from the appserver. thanks. .peter This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information constitute our judgment as of this date and are subject to change without notice. Any information you share with us will be used in the operation of our business, and we do not request and do not want any material, nonpublic information. Absent an express prior written agreement, we are not agreeing to treat any information confidentially and will use any and all information and reserve the right to publish or disclose any information you share with us.
Re: [JBoss-user] Store large pdfs with JBoss
Our Product Data Manager system does the same. Just stores the files on disk with encrypted names. The database has the URLs to the correct PDF for a particular document number. We can reach those URLs on our Apache web server. If trying the JBoss route you could modify your $JAVA_HOME/jre/lib/security/java.policy file to ALL Permissions for your local disk drive. Not very portable then but depends on the application/environment. Not sure how you'd reference the PDFs though. Maybe placing your files under a webapp directory? - Original Message - From: Nelson, Tracy To: '[EMAIL PROTECTED]' Sent: Friday, January 03, 2003 1:07 PM Subject: RE: [JBoss-user] Store large pdfs with JBoss I've always done it with the filesystem. The database just stores the path to the file. Typically you establish some rules for the filesystem store (retention time, max space, maybe use quotas) and have it owned by whatever user the app server runs as. -Original Message-From: Luttrell, Peter [mailto:[EMAIL PROTECTED]]Sent: Friday, January 03, 2003 09:14To: [EMAIL PROTECTED]Subject: [JBoss-user] Store large pdfs with JBoss Has anyone had experience storing large pdfs with jboss, say ~5mbs each? I would like to do it with Oracle and BLOBs, but i've read that there's problems with the drivers and jboss and it doesn't look like it will be possible. Has anyone done with with any other database? Does anyone have ideas on how else to store these files, maybe without a database? I've always thought the filesystem was pretty much off limits from the appserver. thanks. .peter This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information constitute our judgment as of this date and are subject to change without notice. Any information you share with us will be used in the operation of our business, and we do not request and do not want any material, nonpublic information. Absent an express prior written agreement, we are not agreeing to treat any information confidentially and will use any and all information and reserve the right to publish or disclose any information you share with us.
Re: [JBoss-user] CompositeName and JBoss 3.0.4
I haven't had any coffee yet today, so maybe I still a complete dumb ass, but what is a compound name and a composite name. -dain On Friday, January 3, 2003, at 09:09 AM, Michael Huneycutt wrote: After looking at the JBoss code, it appears that JBoss only supports Compound Names and not Composite Names. I have something I am trying to hook up (TopLink), which uses Composite Names. I have no control over this, I found a work around, by I was looking for help in understanding why only Compound Name support and is there a JBoss solution. For more detail look at my post on TopLink in this forum. Thanks Mike H. Sr. Michael Huneycutt Sr. TRC - A perotsystems* Company Email: [EMAIL PROTECTED] Office FL: (813) 891-6084 x47395 Office VA: (804) 934-0977 Cell: (804) 304-7655 URL: www.trcinc.com www.perotsys.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] CompositeName and JBoss 3.0.4
There are not been any call to support CompositeNames since they are for multi-namespace names. What is an example of a CompositeName being generated by TopLink? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Michael Huneycutt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 03, 2003 7:09 AM Subject: [JBoss-user] CompositeName and JBoss 3.0.4 After looking at the JBoss code, it appears that JBoss only supports Compound Names and not Composite Names. I have something I am trying to hook up (TopLink), which uses Composite Names. I have no control over this, I found a work around, by I was looking for help in understanding why only Compound Name support and is there a JBoss solution. For more detail look at my post on TopLink in this forum. Thanks Mike H. Sr. Michael Huneycutt Sr. TRC - A perotsystems* Company Email: [EMAIL PROTECTED] Office FL: (813) 891-6084 x47395 Office VA: (804) 934-0977 Cell: (804) 304-7655 URL: www.trcinc.com www.perotsys.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Store large pdfs with JBoss
Hello All, I would recommend usingsomedocument management system like Plexus IFO or archival storage system like Plexus OSM... advantages: faster, efficient, supportsversion, backups, searching... regards MS -Original Message-From: Nelson, Tracy [mailto:[EMAIL PROTECTED]]Sent: Friday, January 03, 2003 10:08 AMTo: '[EMAIL PROTECTED]'Subject: RE: [JBoss-user] Store large pdfs with JBoss I've always done it with the filesystem. The database just stores the path to the file. Typically you establish some rules for the filesystem store (retention time, max space, maybe use quotas) and have it owned by whatever user the app server runs as. -Original Message-From: Luttrell, Peter [mailto:[EMAIL PROTECTED]]Sent: Friday, January 03, 2003 09:14To: [EMAIL PROTECTED]Subject: [JBoss-user] Store large pdfs with JBoss Has anyone had experience storing large pdfs with jboss, say ~5mbs each? I would like to do it with Oracle and BLOBs, but i've read that there's problems with the drivers and jboss and it doesn't look like it will be possible. Has anyone done with with any other database? Does anyone have ideas on how else to store these files, maybe without a database? I've always thought the filesystem was pretty much off limits from the appserver. thanks. .peter This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information constitute our judgment as of this date and are subject to change without notice. Any information you share with us will be used in the operation of our business, and we do not request and do not want any material, nonpublic information. Absent an express prior written agreement, we are not agreeing to treat any information confidentially and will use any and all information and reserve the right to publish or disclose any information you share with us.
RE: [JBoss-user] Store large pdfs with JBoss
Actuallyi'm considering writing a little jmx service that manages the filesystem store. my ejbs would store the key that the jmx service requires. the service would then enforce/handle all such rules. I just read this however, which articulates some of the concerns with any filesystem approach: From http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html: Why can't EJBs read and write files and directories in the filesystem? And why can't they access file descriptors? Enterprise beans aren't allowed to access files primarily because files are not transactional resources. Allowing EJBs to access files or directories in the filesystem, or to use file descriptors, would compromise component distributability, and would be a security hazard. Another reason is deployability. The EJB container can choose to place an enterprise bean in any JVM, on any machine in a cluster. Yet the contents of a filesystem are not part of a deployment, and are therefore outside of the EJB container's control. File systems, directories, files, and especially file descriptors tend to be machine-local resources. If an enterprise bean running in a JVM on a particular machine is using or holding an open file descriptor to a file in the filesystem, that enterprise bean cannot easily be moved from one JVM or machine to another, without losing its reference to the file. Furthermore, giving EJBs access to the filesystem is a security hazard, since the enterprise bean could potentially read and broadcast the contents of sensitive files, or even upload and overwrite the JVM runtime binary for malicious purposes. Files are not an appropriate mechanism for storing business data for use by components, because they tend to be unstructured, are not under the control of the server environment, and typically don't provide distributed transactional access or fine-grained locking. Business data is better managed using a persistence interface such as JDBC, whose implementations usually provide these benefits. Read-only data can, however, be stored in files in a deployment JAR, and accessed with the getResource() or getResourceAsStream() methods of java.lang.Class. -Original Message-From: James Cleary [mailto:[EMAIL PROTECTED]]Sent: Friday, January 03, 2003 12:37 PMTo: [EMAIL PROTECTED]Subject: Re: [JBoss-user] Store large pdfs with JBoss Our Product Data Manager system does the same. Just stores the files on disk with encrypted names. The database has the URLs to the correct PDF for a particular document number. We can reach those URLs on our Apache web server. If trying the JBoss route you could modify your $JAVA_HOME/jre/lib/security/java.policy file to ALL Permissions for your local disk drive. Not very portable then but depends on the application/environment. Not sure how you'd reference the PDFs though. Maybe placing your files under a webapp directory? - Original Message - From: Nelson, Tracy To: '[EMAIL PROTECTED]' Sent: Friday, January 03, 2003 1:07 PM Subject: RE: [JBoss-user] Store large pdfs with JBoss I've always done it with the filesystem. The database just stores the path to the file. Typically you establish some rules for the filesystem store (retention time, max space, maybe use quotas) and have it owned by whatever user the app server runs as. -Original Message-From: Luttrell, Peter [mailto:[EMAIL PROTECTED]]Sent: Friday, January 03, 2003 09:14To: [EMAIL PROTECTED]Subject: [JBoss-user] Store large pdfs with JBoss Has anyone had experience storing large pdfs with jboss, say ~5mbs each? I would like to do it with Oracle and BLOBs, but i've read that there's problems with the drivers and jboss and it doesn't look like it will be possible. Has anyone done with with any other database? Does anyone have ideas on how else to store these files, maybe without a database? I've always thought the filesystem was pretty much off limits from the appserver. thanks. .peter This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information
RE: [JBoss-user] Store large pdfs with JBoss
Title: Message Agreed.. Jakarta's Slide is another option, as it is an OSSWebDAV-compliant server that will let you configure namespaces for using the filesystem, a DB, or any pluggable store (e.g. /files is for the filestore, while /office_docs is targeted to a DB). It also supports the DeltaV versioning, and comes with a nice client library to talk to the system (over HTTP though, but you may be able to talk directly to it for what you want to do as well.. That API is still under dev AFAIK). http://jakarta.apache.org/slide HTH, James -Original Message-From: Sasidharan, Manoj [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 1:14 PMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-user] Store large pdfs with JBoss Hello All, I would recommend usingsomedocument management system like Plexus IFO or archival storage system like Plexus OSM... advantages: faster, efficient, supportsversion, backups, searching... regards MS -Original Message-From: Nelson, Tracy [mailto:[EMAIL PROTECTED]]Sent: Friday, January 03, 2003 10:08 AMTo: '[EMAIL PROTECTED]'Subject: RE: [JBoss-user] Store large pdfs with JBoss I've always done it with the filesystem. The database just stores the path to the file. Typically you establish some rules for the filesystem store (retention time, max space, maybe use quotas) and have it owned by whatever user the app server runs as. -Original Message-From: Luttrell, Peter [mailto:[EMAIL PROTECTED]]Sent: Friday, January 03, 2003 09:14To: [EMAIL PROTECTED]Subject: [JBoss-user] Store large pdfs with JBoss Has anyone had experience storing large pdfs with jboss, say ~5mbs each? I would like to do it with Oracle and BLOBs, but i've read that there's problems with the drivers and jboss and it doesn't look like it will be possible. Has anyone done with with any other database? Does anyone have ideas on how else to store these files, maybe without a database? I've always thought the filesystem was pretty much off limits from the appserver. thanks. .peter This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information constitute our judgment as of this date and are subject to change without notice. Any information you share with us will be used in the operation of our business, and we do not request and do not want any material, nonpublic information. Absent an express prior written agreement, we are not agreeing to treat any information confidentially and will use any and all information and reserve the right to publish or disclose any information you share with us.
[JBoss-user] CMP dependent value classes from xdoclet
using xdoclet 1.2-b2, is it possible to generate the neccesary dependent-value-classes / block in the jbosscmp-jdbc / file? i have a serializable java object that holds 2 strings, username of who inserted the record, and the date that the object was inserted. these 2 fields map to audit_username and audit_date that i have in every database table. instead of having get/set methods for these i want to wrap audit information into a dependent value class. is it possible to generate this block from xdoclet? Ryan
Re: [JBoss-user] Store large pdfs with JBoss
IMHO, this is a prime example of business data that does not fit the EJB model. And you shouldn't try and shoe horn it in. Its been my understanding that doing the file system access via an MBean is a perfectly permissible way to get around the prohibitions described in the Sun article. Another option is to find or write a JCA wrapper for the Filesystem. Luttrell, Peter wrote: Actuallyi'm considering writing a little jmx service that manages the filesystem store. my ejbs would store the key that the jmx service requires. the service would then enforce/handle all such rules. I just read this however, which articulates some of the concerns with any filesystem approach: From http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html: Why can't EJBs readand write files and directories in the filesystem? And why can't they accessfile descriptors? Enterprise beans aren't allowed to access files primarily because files are not transactional resources. Allowing EJBs to access filesor directories in the filesystem, or to use file descriptors, would compromisecomponent distributability, and would be a security hazard. Another reason is deployability. The EJB container canchoose to place an enterprise bean in any JVM, on any machine in a cluster.Yet the contents of a filesystem are not part of a deployment, and aretherefore outside of the EJB container's control. File systems, directories,files, and especially file descriptors tend to be machine-local resources. Ifan enterprise bean running in a JVM on a particular machine is using orholding an open file descriptor to a file in the filesystem, that enterprisebean cannot easily be moved from one JVM or machine to another, without losingits reference to the file. Furthermore, giving EJBs access to the filesystem is asecurity hazard, since the enterprise bean could potentially read andbroadcast the contents of sensitive files, or even upload and overwrite theJVM runtime binary for malicious purposes. Files are not an appropriate mechanism for storing businessdata for use by components, because they tend to be unstructured, are notunder the control of the server environment, and typically don't providedistributed transactional access or fine-grained locking. Business data isbetter managed using a persistence interface such as JDBC, whose implementations usually provide these benefits. Read-only data can, however, be stored in files in a deployment JAR, and accessed with the getResource() or getResourceAsStream() methods of java.lang.Class. -Original Message- From: James Cleary[mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 12:37PM To: [EMAIL PROTECTED] Subject: Re:[JBoss-user] Store large pdfs with JBoss Our Product Data Manager system does the same.Just stores the files on disk with encrypted names. The database has the URLsto the correct PDF for a particular document number. We can reach those URLson our Apache web server. If trying the JBoss route you could modify your$JAVA_HOME/jre/lib/security/java.policy file to ALL Permissions for your localdisk drive. Not very portable then but depends on the application/environment.Not sure how you'd reference the PDFs though. Maybe placing your files under awebapp directory? - Original Message - From: Nelson, Tracy To: '[EMAIL PROTECTED]' Sent: Friday, January 03, 2003 1:07 PM Subject: RE: [JBoss-user] Store large pdfs with JBoss I've always done it with the filesystem. The database just stores the path to the file. Typically you establish some rules for the filesystem store (retention time, max space, maybe use quotas) and have it owned by whatever user the app server runs as. -Original Message- From: Luttrell, Peter[mailto:[EMAIL PROTECTED]] Sent: Friday, January03, 2003 09:14 To:[EMAIL PROTECTED] Subject: [JBoss-user] Storelarge pdfs with JBoss Has anyone had experiencestoring large pdfs with jboss, say ~5mbs each? I would like to do itwith Oracle and BLOBs, but i've read that there's problems with thedrivers and jboss and it doesn't look like it will be possible. Has anyone done with withany other database? Does anyone have ideas onhow else to store these files, maybe without a database? I've alwaysthought the filesystem was pretty much off
Re: [JBoss-user] Store large pdfs with JBoss
Write a JCA adaptor for a file based persistent store. Scott StarkChief Technology OfficerJBoss Group, LLC - Original Message - From: Luttrell, Peter To: '[EMAIL PROTECTED]' Sent: Friday, January 03, 2003 11:37 AM Subject: RE: [JBoss-user] Store large pdfs with JBoss Actuallyi'm considering writing a little jmx service that manages the filesystem store. my ejbs would store the key that the jmx service requires. the service would then enforce/handle all such rules. I just read this however, which articulates some of the concerns with any filesystem approach: From http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html: Why can't EJBs read and write files and directories in the filesystem? And why can't they access file descriptors? Enterprise beans aren't allowed to access files primarily because files are not transactional resources. Allowing EJBs to access files or directories in the filesystem, or to use file descriptors, would compromise component distributability, and would be a security hazard. Another reason is deployability. The EJB container can choose to place an enterprise bean in any JVM, on any machine in a cluster. Yet the contents of a filesystem are not part of a deployment, and are therefore outside of the EJB container's control. File systems, directories, files, and especially file descriptors tend to be machine-local resources. If an enterprise bean running in a JVM on a particular machine is using or holding an open file descriptor to a file in the filesystem, that enterprise bean cannot easily be moved from one JVM or machine to another, without losing its reference to the file. Furthermore, giving EJBs access to the filesystem is a security hazard, since the enterprise bean could potentially read and broadcast the contents of sensitive files, or even upload and overwrite the JVM runtime binary for malicious purposes. Files are not an appropriate mechanism for storing business data for use by components, because they tend to be unstructured, are not under the control of the server environment, and typically don't provide distributed transactional access or fine-grained locking. Business data is better managed using a persistence interface such as JDBC, whose implementations usually provide these benefits. Read-only data can, however, be stored in files in a deployment JAR, and accessed with the getResource() or getResourceAsStream() methods of java.lang.Class.
Re: [JBoss-user] Store large pdfs with JBoss
generalizing ... generalizing/ write a jca adpter for cvs and use this in a cvs appropriate manner ... bax Write a JCA adaptor for a file based persistent store. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Luttrell, Peter To: '[EMAIL PROTECTED]' Sent: Friday, January 03, 2003 11:37 AM Subject: RE: [JBoss-user] Store large pdfs with JBoss Actually i'm considering writing a little jmx service that manages the filesystem store. my ejbs would store the key that the jmx service requires. the service would then enforce/handle all such rules. I just read this however, which articulates some of the concerns with any filesystem approach: From http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html: Why can't EJBs read and write files and directories in the filesystem? And why can't they access file descriptors? Enterprise beans aren't allowed to access files primarily because files are not transactional resources. Allowing EJBs to access files or directories in the filesystem, or to use file descriptors, would compromise component distributability, and would be a security hazard. Another reason is deployability. The EJB container can choose to place an enterprise bean in any JVM, on any machine in a cluster. Yet the contents of a filesystem are not part of a deployment, and are therefore outside of the EJB container's control. File systems, directories, files, and especially file descriptors tend to be machine-local resources. If an enterprise bean running in a JVM on a particular machine is using or holding an open file descriptor to a file in the filesystem, that enterprise bean cannot easily be moved from one JVM or machine to another, without losing its reference to the file. Furthermore, giving EJBs access to the filesystem is a security hazard, since the enterprise bean could potentially read and broadcast the contents of sensitive files, or even upload and overwrite the JVM runtime binary for malicious purposes. Files are not an appropriate mechanism for storing business data for use by components, because they tend to be unstructured, are not under the control of the server environment, and typically don't provide distributed transactional access or fine-grained locking. Business data is better managed using a persistence interface such as JDBC, whose implementations usually provide these benefits. Read-only data can, however, be stored in files in a deployment JAR, and accessed with the getResource() or getResourceAsStream() methods of java.lang.Class. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Store large pdfs with JBoss
I have been able to put CLOBs and BLOBs into Oracle 9i using JBoss
3.0.4, though admittedly after jumping through several hoops.
1) yes, ejb's aren't supposed to do i/o - I do my work delegated from
the servlet level.
2) You have to have autocommit off. For some reason autocommit is on by
default in JBoss 3 (wasn't in 2.4) from Connections from DataSources.
Please someone tell me how to turn this off in a global config somewhere!
3) You have to first insert a row using an empty lob. For example,
insert into my_table (key, data) values ('1', empty_blob())
. You could have used empty_clob() if you were using CLOBS instead of
BLOBS.
4) You can then update the BLOB, hower you have to re-select *** using
select for update ***. If you don't use select for update, ** it won't
work **. For example,
select data from my_table where key = '1' for update
5) You then can update the BLOB from the ResultSet. Notice I said
oracle.sql.BLOB not java.sql.Blob. I had to use an Oracle-specific type
here. I couldn't get it to work any other way, and I spent hours (no,
setBinaryStream does not work)... For example,
BLOB blob = (BLOB)rs.getBlob(1);
BufferedOutputStream bos =
new BufferedOutputStream( blob.getBinaryOutputStream() );
// write to the output stream
// safely close everything up
6) Don't forget to commit the work you did. This will commit the insert
and the data your wrote to your BLOB.
7) I set the autocommit on the Connection back to what it was when I
first got it from the DataSource, before I close it (the Connection,
which returns it to the pool). Again, I'd like to see autocommit off
since I wrap everything in a UserTransaction and it should be committed
there instead...
Hope this will save you some of the painful time I had to go through if
you decide to go this route.
David
--
Luttrell, Peter escribió::
Has anyone had experience storing large pdfs with jboss, say ~5mbs each?
I would like to do it with Oracle and BLOBs, but i've read that there's
problems with the drivers and jboss and it doesn't look like it will be
possible.
Has anyone done with with any other database?
Does anyone have ideas on how else to store these files, maybe without a
database? I've always thought the filesystem was pretty much off limits
from the appserver.
thanks.
.peter
This transmission contains information solely for intended recipient and
may be privileged, confidential and/or otherwise protect from
disclosure. If you are not the intended recipient, please contact the
sender and delete all copies of this transmission. This message and/or
the materials contained herein are not an offer to sell, or a
solicitation of an offer to buy, any securities or other instruments.
The information has been obtained or derived from sources believed by us
to be reliable, but we do not represent that it is accurate or complete.
Any opinions or estimates contained in this information constitute our
judgment as of this date and are subject to change without notice. Any
information you share with us will be used in the operation of our
business, and we do not request and do not want any material, nonpublic
information. Absent an express prior written agreement, we are not
agreeing to treat any information confidentially and will use any and
all information and reserve the right to publish or disclose any
information you share with us.
--
-
David Ward
[EMAIL PROTECTED]
http://www.dotech.com
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Store large pdfs with JBoss
A WebDAV adapter would be another option. Peter Callies McKesson Information Solutions Transaction Solutions Hub mailto:[EMAIL PROTECTED] Phone: (952) 814-7163 Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. -Original Message-From: Scott M Stark [mailto:[EMAIL PROTECTED]]Sent: Friday, January 03, 2003 2:37 PMTo: [EMAIL PROTECTED]Subject: Re: [JBoss-user] Store large pdfs with JBoss Write a JCA adaptor for a file based persistent store. Scott StarkChief Technology OfficerJBoss Group, LLC - Original Message - From: Luttrell, Peter To: '[EMAIL PROTECTED]' Sent: Friday, January 03, 2003 11:37 AM Subject: RE: [JBoss-user] Store large pdfs with JBoss Actuallyi'm considering writing a little jmx service that manages the filesystem store. my ejbs would store the key that the jmx service requires. the service would then enforce/handle all such rules. I just read this however, which articulates some of the concerns with any filesystem approach: From http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html: Why can't EJBs read and write files and directories in the filesystem? And why can't they access file descriptors? Enterprise beans aren't allowed to access files primarily because files are not transactional resources. Allowing EJBs to access files or directories in the filesystem, or to use file descriptors, would compromise component distributability, and would be a security hazard. Another reason is deployability. The EJB container can choose to place an enterprise bean in any JVM, on any machine in a cluster. Yet the contents of a filesystem are not part of a deployment, and are therefore outside of the EJB container's control. File systems, directories, files, and especially file descriptors tend to be machine-local resources. If an enterprise bean running in a JVM on a particular machine is using or holding an open file descriptor to a file in the filesystem, that enterprise bean cannot easily be moved from one JVM or machine to another, without losing its reference to the file. Furthermore, giving EJBs access to the filesystem is a security hazard, since the enterprise bean could potentially read and broadcast the contents of sensitive files, or even upload and overwrite the JVM runtime binary for malicious purposes. Files are not an appropriate mechanism for storing business data for use by components, because they tend to be unstructured, are not under the control of the server environment, and typically don't provide distributed transactional access or fine-grained locking. Business data is better managed using a persistence interface such as JDBC, whose implementations usually provide these benefits. Read-only data can, however, be stored in files in a deployment JAR, and accessed with the getResource() or getResourceAsStream() methods of java.lang.Class.
Re: [JBoss-user] Store large pdfs with JBoss
Greg, I completely disagree; this is not a problem with CMP but the implementations. The problem with every app server available including JBoss is the CMP engine is a black box. In 4.0, I plan on opening this up so anyone can fairly easily write a physical persistence store manager. This would mean that for this case, Peter could have all the data for a the entity in a JDBC data store except for the file which would be stored via a filesystem physical store manager. Entity beans provide a good interface to an abstract store system. Also with the aspect stuff you will be able to use the same abstract store system from an even easier interface. -dain On Friday, January 3, 2003, at 02:34 PM, Greg Turner wrote: IMHO, this is a prime example of business data that does not fit the EJB model. And you shouldn't try and shoe horn it in. Its been my understanding that doing the file system access via an MBean is a perfectly permissible way to get around the prohibitions described in the Sun article. Another option is to find or write a JCA wrapper for the Filesystem. Luttrell, Peter wrote: Actually i'm considering writing a little jmx service that manages the filesystem store. my ejbs would store the key that the jmx service requires. the service would then enforce/handle all such rules. I just read this however, which articulates some of the concerns with any filesystem approach: Fromhttp://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html: Why can't EJBs read and write files and directories in the filesystem? And why can't they access file descriptors? Enterprise beans aren't allowed to access files primarily because files are not transactional resources. Allowing EJBs to access files or directories in the filesystem, or to use file descriptors, would compromise component distributability, and would be a security hazard. Another reason is deployability. The EJB container can choose to place an enterprise bean in any JVM, on any machine in a cluster. Yet the contents of a filesystem are not part of a deployment, and are therefore outside of the EJB container's control. File systems, directories, files, and especially file descriptors tend to be machine-local resources. If an enterprise bean running in a JVM on a particular machine is using or holding an open file descriptor to a file in the filesystem, that enterprise bean cannot easily be moved from one JVM or machine to another, without losing its reference to the file. Furthermore, giving EJBs access to the filesystem is a security hazard, since the enterprise bean could potentially read and broadcast the contents of sensitive files, or even upload and overwrite the JVM runtime binary for malicious purposes. Files are not an appropriate mechanism for storing business data for use by components, because they tend to be unstructured, are not under the control of the server environment, and typically don't provide distributed transactional access or fine-grained locking. Business data is better managed using a persistence interface such as JDBC, whose implementations usually provide these benefits. Read-only data can, however, be stored in files in a deployment JAR, and accessed with the getResource() or getResourceAsStream() methods of java.lang.Class. -Original Message- From: James Cleary [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 12:37 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Store large pdfs with JBoss Our Product Data Manager system does the same. Just stores the files on disk with encrypted names. The database has the URLs to the correct PDF for a particular document number. We can reach those URLs on our Apache web server. If trying the JBoss route you could modify your $JAVA_HOME/jre/lib/security/java.policy file to ALL Permissions for your local disk drive. Not very portable then but depends on the application/environment. Not sure how you'd reference the PDFs though. Maybe placing your files under a webapp directory? - Original Message - From: Nelson, Tracy To: '[EMAIL PROTECTED]' Sent: Friday, January 03, 2003 1:07 PM Subject: RE: [JBoss-user] Store large pdfs with JBoss I've always done it with the filesystem. The database just stores the path to the file. Typically you establish some rules for the filesystem store (retention time, max space, maybe use quotas) and have it owned by whatever user the app server runs as. -Original Message- From: Luttrell, Peter [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 09:14 To: [EMAIL PROTECTED] Subject: [JBoss-user] Store large pdfs with JBoss Has anyone had experience storing large pdfs with jboss, say ~5mbs each? I would like to do it with Oracle and BLOBs, but i've read that there's problems with the drivers and jboss and it doesn't look like it will be possible. Has anyone done with with any other database? Does anyone have ideas on how else
RE: [JBoss-user] Store large pdfs with JBoss
Admittedly i don't know much about JCA. Does anyone have skeleton code or a sample they care to share? thanks. .peter -Original Message-From: Scott M Stark [mailto:[EMAIL PROTECTED]]Sent: Friday, January 03, 2003 2:37 PMTo: [EMAIL PROTECTED]Subject: Re: [JBoss-user] Store large pdfs with JBoss Write a JCA adaptor for a file based persistent store. Scott StarkChief Technology OfficerJBoss Group, LLC - Original Message - From: Luttrell, Peter To: '[EMAIL PROTECTED]' Sent: Friday, January 03, 2003 11:37 AM Subject: RE: [JBoss-user] Store large pdfs with JBoss Actuallyi'm considering writing a little jmx service that manages the filesystem store. my ejbs would store the key that the jmx service requires. the service would then enforce/handle all such rules. I just read this however, which articulates some of the concerns with any filesystem approach: From http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html: Why can't EJBs read and write files and directories in the filesystem? And why can't they access file descriptors? Enterprise beans aren't allowed to access files primarily because files are not transactional resources. Allowing EJBs to access files or directories in the filesystem, or to use file descriptors, would compromise component distributability, and would be a security hazard. Another reason is deployability. The EJB container can choose to place an enterprise bean in any JVM, on any machine in a cluster. Yet the contents of a filesystem are not part of a deployment, and are therefore outside of the EJB container's control. File systems, directories, files, and especially file descriptors tend to be machine-local resources. If an enterprise bean running in a JVM on a particular machine is using or holding an open file descriptor to a file in the filesystem, that enterprise bean cannot easily be moved from one JVM or machine to another, without losing its reference to the file. Furthermore, giving EJBs access to the filesystem is a security hazard, since the enterprise bean could potentially read and broadcast the contents of sensitive files, or even upload and overwrite the JVM runtime binary for malicious purposes. Files are not an appropriate mechanism for storing business data for use by components, because they tend to be unstructured, are not under the control of the server environment, and typically don't provide distributed transactional access or fine-grained locking. Business data is better managed using a persistence interface such as JDBC, whose implementations usually provide these benefits. Read-only data can, however, be stored in files in a deployment JAR, and accessed with the getResource() or getResourceAsStream() methods of java.lang.Class. This transmission contains information solely for intended recipient and may be privileged, confidential and/or otherwise protect from disclosure. If you are not the intended recipient, please contact the sender and delete all copies of this transmission. This message and/or the materials contained herein are not an offer to sell, or a solicitation of an offer to buy, any securities or other instruments. The information has been obtained or derived from sources believed by us to be reliable, but we do not represent that it is accurate or complete. Any opinions or estimates contained in this information constitute our judgment as of this date and are subject to change without notice. Any information you share with us will be used in the operation of our business, and we do not request and do not want any material, nonpublic information. Absent an express prior written agreement, we are not agreeing to treat any information confidentially and will use any and all information and reserve the right to publish or disclose any information you share with us.
Re: [JBoss-user] Store large pdfs with JBoss
Scott M Stark escribió:: Write a JCA adaptor for a file based persistent store. -- You say that like it's so easy Scott... ;) Seriously, what is Oracle underneath all the cool stuff but a file based persistent store. Anyway, if you are going to indeed write your own jca adapter, instead of starting from scratch here is a possible place to start. Granted, there is nothing in the code that has anything to do with the JCA spec, but it points out some stuff you will need to keep in mind when you implement one: http://www.onjava.com/pub/a/onjava/2001/11/07/atomic.html http://www.onjava.com/onjava/2001/11/07/examples/atomic.zip David --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Announcement - JBoss Handbook
Hi, I am pleased to announce the availability of the book "JBoss 3.0 Deployment and Administration Handbook". The book provides a comprehensive coverage of the JBoss 3.0 server, focusing on -JBoss architecture -Deploying and configuring EJBs, web applications, EAR files, JCA resource adapters, JMX MBeans etc on JBoss-JBoss CMP 2.0 features-JBoss clustering-Configuring JMS and JCA-Configuring security, logging, JavaMail -JBoss custom features like scheduling-Administration and monitoring of the server. The book will be a valuable resource for anyone using JBoss in production and development.The book is published by WROX Press and is available on Amazon, http://www.amazon.com/exec/obidos/tg/detail/-/1861008120/qid=1041628886/sr=8-1/ref=sr_8_1/104-6889188-8834314?v=glances=booksn=507846 Let me also take this opportunity to express my immense gratitude to all the JBoss developers who have made this book possible. Thanks MeerajDo you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now
Re: [JBoss-user] Store large pdfs with JBoss
Dain, OK. I see what you are saying. I agree. Thanks. Greg Dain Sundstrom wrote: Greg, I completely disagree; this is not a problem with CMP but the implementations. The problem with every app server available including JBoss is the CMP engine is a black box. In 4.0, I plan on opening this up so anyone can fairly easily write a physical persistence store manager. This would mean that for this case, Peter could have all the data for a the entity in a JDBC data store except for the file which would be stored via a filesystem physical store manager. Entity beans provide a good interface to an abstract store system. Also with the aspect stuff you will be able to use the same abstract store system from an even easier interface. -dain On Friday, January 3, 2003, at 02:34 PM, Greg Turner wrote: IMHO, this is a prime example of business data that does not fit the EJB model. And you shouldn't try and shoe horn it in. Its been my understanding that doing the file system access via an MBean is a perfectly permissible way to get around the prohibitions described in the Sun article. Another option is to find or write a JCA wrapper for the Filesystem. Luttrell, Peter wrote: Actually i'm considering writing a little jmx service that manages the filesystem store. my ejbs would store the key that the jmx service requires. the service would then enforce/handle all such rules. I just read this however, which articulates some of the concerns with any filesystem approach: Fromhttp://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html: Why can't EJBs read and write files and directories in the filesystem? And why can't they access file descriptors? Enterprise beans aren't allowed to access files primarily because files are not transactional resources. Allowing EJBs to access files or directories in the filesystem, or to use file descriptors, would compromise component distributability, and would be a security hazard. Another reason is deployability. The EJB container can choose to place an enterprise bean in any JVM, on any machine in a cluster. Yet the contents of a filesystem are not part of a deployment, and are therefore outside of the EJB container's control. File systems, directories, files, and especially file descriptors tend to be machine-local resources. If an enterprise bean running in a JVM on a particular machine is using or holding an open file descriptor to a file in the filesystem, that enterprise bean cannot easily be moved from one JVM or machine to another, without losing its reference to the file. Furthermore, giving EJBs access to the filesystem is a security hazard, since the enterprise bean could potentially read and broadcast the contents of sensitive files, or even upload and overwrite the JVM runtime binary for malicious purposes. Files are not an appropriate mechanism for storing business data for use by components, because they tend to be unstructured, are not under the control of the server environment, and typically don't provide distributed transactional access or fine-grained locking. Business data is better managed using a persistence interface such as JDBC, whose implementations usually provide these benefits. Read-only data can, however, be stored in files in a deployment JAR, and accessed with the getResource() or getResourceAsStream() methods of java.lang.Class. -Original Message- From: James Cleary [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 12:37 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Store large pdfs with JBoss Our Product Data Manager system does the same. Just stores the files on disk with encrypted names. The database has the URLs to the correct PDF for a particular document number. We can reach those URLs on our Apache web server. If trying the JBoss route you could modify your $JAVA_HOME/jre/lib/security/java.policy file to ALL Permissions for your local disk drive. Not very portable then but depends on the application/environment. Not sure how you'd reference the PDFs though. Maybe placing your files under a webapp directory? - Original Message - From: Nelson, Tracy To: '[EMAIL PROTECTED]' Sent: Friday, January 03, 2003 1:07 PM Subject: RE: [JBoss-user] Store large pdfs with JBoss I've always done it with the filesystem. The database just stores the path to the file. Typically you establish some rules for the filesystem store (retention time, max space, maybe use quotas) and have it owned by whatever user the app server runs as. -Original Message- From: Luttrell, Peter [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 09:14 To: [EMAIL PROTECTED] Subject: [JBoss-user] Store large pdfs with JBoss Has anyone had experience storing large pdfs with jboss, say ~5mbs each? I would like to do it with Oracle and BLOBs, but i've read that there's problems with the drivers and jboss and it doesn't look like it will be
Re: [JBoss-user] Announcement - JBoss Handbook
Awesome. I put in my order already. --- Meeraj Kunnumpurath [EMAIL PROTECTED] wrote: Hi, I am pleased to announce the availability of the book JBoss 3.0 Deployment and Administration Handbook. The book provides a comprehensive coverage of the JBoss 3.0 server, focusing on -JBoss architecture -Deploying and configuring EJBs, web applications, EAR files, JCA resource adapters, JMX MBeans etc on JBoss -JBoss CMP 2.0 features -JBoss clustering -Configuring JMS and JCA -Configuring security, logging, JavaMail -JBoss custom features like scheduling -Administration and monitoring of the server. The book will be a valuable resource for anyone using JBoss in production and development.The book is published by WROX Press and is available on Amazon, http://www.amazon.com/exec/obidos/tg/detail/-/1861008120/qid=1041628886/sr=8-1/ref=sr_8_1/104-6889188-8834314?v=glances=booksn=507846 Let me also take this opportunity to express my immense gratitude to all the JBoss developers who have made this book possible. Thanks Meeraj - Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now = Nicholas Whitehead Home: (973) 377 9335 Cell: (201) 615 2716 Work: (212) 622 5639 [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re[2]: [JBoss-user] jetty bug?
Hello Jules, Wednesday, January 01, 2003, 9:36:26 PM, you wrote: I have just updated the Jetty on Branch_3_0 to 4.2.x. ... Use -r Branch_3_0 and the module name jboss-3.0 (from memory) If the problem persists in this latest version, we will look at it. Nothing changed :-( Upgrade to struts 1.1b3 didn't help too. A short piece of jboss's log follows below - cookie looks really dead - what can be a real reason for that? DEBUG [gui2.servlets.system.GUIActionServlet] Session is dead and no autologin parameters, session=null ,seance=null, request=/gui2+/system/login.do+null POST /gui2/system/login.do HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, */* Referer: http://127.0.0.1:8080/gui2/login.jsp Accept-Language: ru Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; MyIE2 0.3) Host: 127.0.0.1:8080 Content-Length: 41 Connection: keep-alive Cache-Control: no-cache Cookie: JSESSIONID= -- Vale! - Mikhail Akopov --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Re: HELP - JBoss 3.0.4/Oracle TopLink 9.0.3/JTS/Oracle (XADataSource/DataSource
Quick HOW-TO Setting up: TopLink 9.0.3/Oracle (8.1.7,9.2,9.0)/Oracle XA DataSource/JBoss 3.0.4/JDK1.4.1 1. Run initjvm.sql and initxa.sql in the oracle databases that you will be connecting to with the Oracle XA DataSources configured in JBoss. They can be found in $ORACLE_HOME/javavm/install. 2. Get the latest Oracle JDBC Driver from http://technet.oracle.com. The one I used is the latest and is named ojdbc14.jar (not classes12.zip). 3. Copy $JBOSS_HOME/docs/examples/jca/ oracle-xa-service.xml to the appropriate $JBOSS_HOME/server/[all|default|minimal]/deploy and configure it for your database. 4. Modify $JBOSS_HOME/server/[all|default|minimal]/conf/ jboss-service.xml to include the attribute pad true for the XidFactory. It should look as follows: mbean code=org.jboss.tm.XidFactory name=jboss:service=XidFactory attribute name=Padtrue/attribute /mbean 5. In your code to connect up to JNDI using the TopLink JNDIConnector you will need to lookup and get the DataSource yourself and pass it in the JNDIConnector constructor. If you user the a jndi name string the JNDIConnector will generate a CompositeName, which results in a InvalidNamingException - not a CompoundName. It appears that CompositeNames do not work in JBoss 3.0.4. Here is some sample code: //jndiProperties are the your properties Context context = InitialContext(jndiProperties); javax.sql.DataSource ds = (javax.sql.DataSource) context.lookup( java:/XATestDS); JNDIConnector connector = new JNDIConnector(ds); login.setConnector(connector); 6. You will need to write code to lookup and get the JBoss TransactionManager and then use the TopLink JTSSynchronizationListener to set the transaction manager so TopLink knows about it. The following code is an example: import javax.transaction.TransactionManager; import oracle.toplink.jts.*; .. TransactionManager tm = (TransactionManager)context.lookup( transactionMgrJndiName); JTSSynchronizationListener. setTransactionManager(tm); 7. Finally you need to also set in TopLink the the external JTS Controller class and let TopLink know you want to use external transactions. The generic TopLink class JTSExternalTransactionController seems to work so far. An example: login.useExternalTransactionController(); String jtsControllerClassName = JTSExternalTransactionController; Class jtsControllerClass = Thread .currentThread() .getContextClassLoader() .loadClass( jtsControllerClassName); ExternalTransactionController jtsController = (ExternalTransactionController) jtsControllerClass .newInstance(); serverSession.setExternalTransactionController( jtsController); login.useExternalConnectionPooling(); That does it. Hopefully this helps others who may struggle as well. Mike H. Sr. Michael Huneycutt Sr. TRC - A perotsystems* Company Email: [EMAIL PROTECTED] Office FL: (813) 891-6084 x47395 Office VA: (804) 934-0977 Cell: (804) 304-7655 URL: www.trcinc.com www.perotsys.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Re: HELP - JBoss 3.0.4/Oracle TopLink 9.0.3/JTS/Oracle (XADataSource/DataSource
Turns out that initxa.sql and initjvm.sql had not been run in the database I was trying to connect to. I confirmed this by connecting to a database that has JAVA_XA installed and the Oracle XA DataSource worked fine. Thanks Mike H. Sr. Michael Huneycutt Sr. TRC - A perotsystems* Company Email: [EMAIL PROTECTED] Office FL: (813) 891-6084 x47395 Office VA: (804) 934-0977 Cell: (804) 304-7655 URL: www.trcinc.com www.perotsys.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Re: [JBoss-dev] 3.0.5RC1 available
On Tue, 24 Dec 2002, Scott M Stark wrote: A 3.0.5 pre-release has been made available for testing. The primary purpse is to get feedback about the latest class loader changes made to address the outstanding IllegalAccessErrors. If you have experienced problems with IllegalAccessErrors or LinkageErrors please try this version or the 3.2.0beta3 version. Both are available from SourceForge here: http://sourceforge.net/project/showfiles.php?group_id=22866 If you experience any class loading related problems follow the bug reporting proceedure described in the release notes: http://sourceforge.net/project/shownotes.php?release_id=129789 Downloaded the 3.0.5RC1-tomcat4.1.18 version. Unpacked. did bin/run.sh. Got this error: 17:58:11,026 ERROR [MainDeployer] could not create deployment: file:/home.local/adam/brainfood/jboss/3.0.5rc1/server/default/conf/jboss-servi ce.xml org.jboss.deployment.DeploymentException: instantiating org.jboss.varia.property.PropertyEditorManagerService failed: java.lang.NoClassDefFou ndError: org/jboss/net/protocol/jar/Handler (wrong name: org/jboss/varia/property/PropertyEditorManagerService); - nested throwable: (Runtime ErrorException: instantiating org.jboss.varia.property.PropertyEditorManagerService failed: java.lang.NoClassDefFoundError: org/jboss/net/pro tocol/jar/Handler (wrong name: org/jboss/varia/property/PropertyEditorManagerService) Cause: java.lang.NoClassDefFoundError: org/jboss/net/protocol/jar/Handler (wrong name: org/jboss/varia/property/PropertyEditorManagerService) ) Running this shell snippet: for a in `find -name '*.jar'`;do if unzip -lv $a |grep org/jboss/net/protocol;then echo $a;fi;done Find something about an njar handler, but no jar handler. So, for me, 3.0.5RC1 is dead in the water. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Announcement - JBoss Handbook
On Fri, 2003-01-03 at 16:48, Meeraj Kunnumpurath wrote: I am pleased to announce the availability of the book JBoss 3.0 Deployment and Administration Handbook. The book provides a comprehensive coverage of the JBoss 3.0 server, focusing on Is this the same book that comes in the electronic subscription or is this a different book? If it is in the subscription, how do we upgrade? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
