Web app questions

[Egor Savotchkin]

Hi all,
I'm trying to set up a small application similar to Java Pet Store Web
Tier and
I got the following problems/questions:

1)  my main servlet main.jsp is mapped to /control/*, I set up a protected
zone at /control/signin but unfortunately when I go to /control/signin orion
server serves me main.jsp. Is it a bug or that's my (and JPD engeneers')
misunderstading of the spec?
2) I thought I could work around this problem by setting up a new protected
domain which is not under control directory. So I added the following lines
in web.xml:
  

  Authentication zone
  no description
  /protected/signin.jsp
  POST
  GET


  no description
  customer
  subscriber


  no description
  NONE

  
  
FORM


  /login.jsp
  /error.html

  
now when I try to access /protected/signin.jsp I see my login dialog but
after I press sumbit button Orion shows me:
"403 Forbidden
Directory browsing not allowed"
!! What does it mean? The /protected/signin.jsp does exists, did it
authenticate me? !!!
3) I have refs to images in login.jsp ("images/...")  and when login form
appears in response to "protected/signin.jsp" the server couldn't find them,
but the original login.jsp is just under context root! How come it cannot
find images directory which does exist? Maybe login.jsp is invoked as it
were located in /protected directory?

Thanks in advance, Egor.

RE: worked under 0.9.4 broken under 0.9.6

[Walker, Eric]

Having another 0.9.4 vs 0.9.6 problem:

public ConfigDAO(Connection connection) throws SQLException
{
fConnection = connection;
try
{
vStatements.put("INSERT_PROPERTY",
fConnection.prepareStatement("INSERT INTO CONFIG (CONFIGKEY, VALUE,
CONFIGKEYNAME, DESCRIPTION, CONFIGGROUP) VALUES (?, ?, ?, ?, ?)"));

vStatements.put("UPDATE_PROPERTY",
fConnection.prepareStatement("UPDATE CONFIG SET VALUE = ?, CONFIGKEYNAME =
?, DESCRIPTION = ?, CONFIGGROUP = ? WHERE CONFIGKEY = ?"));
vStatements.put("UPDATE_PROPERTY_VALUE",
fConnection.prepareStatement("UPDATE CONFIG SET VALUE = ? WHERE CONFIGKEY =
?"));

vStatements.put("DELETE_PROPERTY",
fConnection.prepareStatement("DELETE FROM CONFIG WHERE CONFIGKEY = ?"));

vStatements.put("SELECT_PROPERTY_VALUE",
fConnection.prepareStatement("SELECT VALUE FROM CONFIG WHERE CONFIGKEY =
?"));
vStatements.put("SELECT_ALL_PROPERTIES",
fConnection.prepareStatement("SELECT VALUE, CONFIGKEYNAME, DESCRIPTION,
CONFIGGROUP FROM CONFIG"));
//   vStatements.put("SELECT_BY_GROUPS",
fConnection.prepareStatement("SELECT VALUE, CONFIGKEYNAME, DESCRIPTION FROM
CONFIG WHERE CONFIGGROUP = ?"));

}
catch (Exception e)
{
throw new ConfigException(e.getMessage(), e);
}
}

fConnection.prepareStatement works under 0.9.4 throws NullPointer Exception
under 0.9.6

Thanks

Eric

-Original Message-
From: Walker, Eric [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 25, 2000 4:43 PM
To: Orion-Interest
Subject: worked under 0.9.4 broken under 0.9.6


the following code snippet worked under 0.9.4 but generates a
NullPointerException under 0.9.6. The offending line is the lookup:

private IConfig getConfigBean()
{
if( m_configBean != null )
{
return m_configBean;
}

try
{
InitialContext initialContext = new
InitialContext();
Object obj =
initialContext.lookup("java:comp/env/ejb/ssp/StashHome");
ConfigHome configHome =
(ConfigHome)PortableRemoteObject.narrow(obj,ConfigHome.class);
m_configBean = configHome.create();
}
catch (Exception e)
{
  e.printStackTrace();
System.out.println("Can't get Configuation bean. No
items will be available!");
}

return m_configBean;
}

Any ideas?

Thanks
Eric Walker

Re: Persisting Entity Beans to Hard-Disk

[Joe Walnes]

>I need to find out how one persists an Entity Bean to Disk as opposed to a
>Database.  The J2EE developer docs suggest that no use can be made of the
>java.io package within an Entity Bean.  This indicates to me that I should
>be using services provided by the Orion container in order to do this.  I
>can't find these services however and would appreciate some information
>regarding how I should go about this.

It is feasible to do this, by rolling your own persistance daemon which can 
do something like run in another VM (or thread with appropriate privileges) 
and handle all file writing/reading and be available via RMI (or another 
transport layer). The main reason this is not advised is that the 
data-stores need to exhibit transactional features - the application server 
can not utilise these if they do not exist.

-Joe Walnes