You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by do...@apache.org on 2002/09/06 11:42:35 UTC
cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces ApplicationContext.java Kernel.java
donaldp 2002/09/06 02:42:35
Modified: src/java/org/apache/avalon/phoenix BlockContext.java
src/java/org/apache/avalon/phoenix/components/application
DefaultBlockContext.java
src/java/org/apache/avalon/phoenix/components/classloader
DefaultPolicy.java
src/java/org/apache/avalon/phoenix/components/deployer
DefaultDeployer.java
src/java/org/apache/avalon/phoenix/components/kernel
DefaultApplicationContext.java DefaultKernel.java
SarEntry.java
src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Added: src/java/org/apache/avalon/phoenix/components/util
ResourceUtil.java
Log:
Implement BlockContext.getResourceAsStream() so that a block is capable of
locating resources in the sar file. This method will retrieve the resource
regardless of where it is located.
This allows blocks to aquire resources regardless of where they are located;
* in base directory
* in work directory
* in .sar file (in future)
* in some vfs (in future)
Revision Changes Path
1.15 +13 -8 jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/BlockContext.java
Index: BlockContext.java
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/BlockContext.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- BlockContext.java 31 Aug 2002 06:34:00 -0000 1.14
+++ BlockContext.java 6 Sep 2002 09:42:35 -0000 1.15
@@ -8,6 +8,7 @@
package org.apache.avalon.phoenix;
import java.io.File;
+import java.io.InputStream;
import org.apache.avalon.framework.context.Context;
import org.apache.avalon.framework.logger.Logger;
@@ -51,6 +52,18 @@
void requestShutdown();
/**
+ * Retrieve a resource from the SAR file. The specified
+ * name is relative the root of the archive. So you could
+ * use it to retrieve a html page from within sar by loading
+ * the resource named "data/main.html" or similar.
+ * Names may be prefixed with '/' character.
+ *
+ * @param name the name of resource
+ * @return the InputStream for resource or null if no such resource
+ */
+ InputStream getResourceAsStream( String name );
+
+ /**
* Retrieve logger coresponding to named category.
*
* @return the logger
@@ -99,14 +112,6 @@
* getProxy( Object other )
*/
//Object getProxy( Object other, Class[] interfaces );
-
- /**
- * Retrieve a resource from the SAR file. The specified
- * name is relative the root of the archive. So you could
- * use it to retrieve a html page from within sar by loading
- * the resource named "data/main.html" or similar.
- */
- //InputStream getResourceAsStream( String name );
/**
* This method gives you access to a named ClassLoader. The ClassLoaders
1.19 +6 -0 jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/components/application/DefaultBlockContext.java
Index: DefaultBlockContext.java
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/components/application/DefaultBlockContext.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- DefaultBlockContext.java 31 Aug 2002 06:34:00 -0000 1.18
+++ DefaultBlockContext.java 6 Sep 2002 09:42:35 -0000 1.19
@@ -8,6 +8,7 @@
package org.apache.avalon.phoenix.components.application;
import java.io.File;
+import java.io.InputStream;
import org.apache.avalon.framework.context.ContextException;
import org.apache.avalon.framework.logger.Logger;
import org.apache.avalon.phoenix.BlockContext;
@@ -77,6 +78,11 @@
public void requestShutdown()
{
m_applicationContext.requestShutdown();
+ }
+
+ public InputStream getResourceAsStream( final String name )
+ {
+ return m_applicationContext.getResourceAsStream( name );
}
/**
1.12 +4 -51 jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/components/classloader/DefaultPolicy.java
Index: DefaultPolicy.java
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/components/classloader/DefaultPolicy.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- DefaultPolicy.java 6 Aug 2002 11:57:39 -0000 1.11
+++ DefaultPolicy.java 6 Sep 2002 09:42:35 -0000 1.12
@@ -28,6 +28,7 @@
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.configuration.ConfigurationException;
import org.apache.avalon.framework.context.DefaultContext;
+import org.apache.avalon.phoenix.components.util.ResourceUtil;
/**
* Policy that extracts information from policy files.
@@ -41,14 +42,6 @@
private static final Resources REZ =
ResourceManager.getPackageResources( DefaultPolicy.class );
- private static final String SAR_PROTOCOL = "sar:";
-
- private static final String SAR_INF = SAR_PROTOCOL + "SAR-INF/";
-
- private static final String CLASSES = SAR_INF + "classes";
-
- private static final String LIB = SAR_INF + "lib";
-
private final File m_baseDirectory;
private final File m_workDirectory;
@@ -188,7 +181,9 @@
if( null != codeBase )
{
codeBase = expand( codeBase );
- codeBase = expandSarURL( codeBase );
+ codeBase = ResourceUtil.expandSarURL( codeBase,
+ m_baseDirectory,
+ m_workDirectory );
}
final Certificate[] signers = getSigners( signedBy, keyStoreName, keyStores );
@@ -241,48 +236,6 @@
final Permission permission = createPermission( type, target, actions, signers );
permissions.add( permission );
- }
-
- /**
- * Expand any URLs with sar: protocol so that
- * they accurately match the actual location
- *
- * @param codeBase the input url
- * @return the result url, modified to file url if it
- * is protocol "sar:"
- * @throws ConfigurationException if invalidly specified URL
- */
- private String expandSarURL( final String codeBase )
- throws ConfigurationException
- {
- if( codeBase.startsWith( SAR_PROTOCOL ) )
- {
- final String filename =
- codeBase.substring( 4 ).replace( '/', File.separatorChar );
- File baseDir = null;
- if( codeBase.startsWith( CLASSES )
- || codeBase.startsWith( LIB ) )
- {
- baseDir = m_workDirectory;
- }
- else
- {
- baseDir = m_baseDirectory;
- }
- final File file = new File( baseDir, filename );
- try
- {
- return file.toURL().toString();
- }
- catch( MalformedURLException e )
- {
- throw new ConfigurationException( e.getMessage(), e );
- }
- }
- else
- {
- return codeBase;
- }
}
private String expand( final String value )
1.54 +5 -1 jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/components/deployer/DefaultDeployer.java
Index: DefaultDeployer.java
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/components/deployer/DefaultDeployer.java,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -r1.53 -r1.54
--- DefaultDeployer.java 6 Sep 2002 07:03:58 -0000 1.53
+++ DefaultDeployer.java 6 Sep 2002 09:42:35 -0000 1.54
@@ -337,7 +337,11 @@
m_logManager.createHierarchy( metaData, logs, classLoader );
//Finally add application to kernel
- m_kernel.addApplication( metaData, classLoader, logger, environment );
+ m_kernel.addApplication( metaData,
+ installation.getWorkDirectory(),
+ classLoader,
+ logger,
+ environment );
m_installations.put( metaData.getName(), installation );
1.29 +49 -0 jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/components/kernel/DefaultApplicationContext.java
Index: DefaultApplicationContext.java
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/components/kernel/DefaultApplicationContext.java,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- DefaultApplicationContext.java 31 Aug 2002 06:34:00 -0000 1.28
+++ DefaultApplicationContext.java 6 Sep 2002 09:42:35 -0000 1.29
@@ -7,6 +7,10 @@
*/
package org.apache.avalon.phoenix.components.kernel;
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.InputStream;
+import java.io.FileNotFoundException;
import java.util.HashMap;
import org.apache.avalon.excalibur.i18n.ResourceManager;
import org.apache.avalon.excalibur.i18n.Resources;
@@ -18,6 +22,7 @@
import org.apache.avalon.framework.service.ServiceException;
import org.apache.avalon.framework.service.ServiceManager;
import org.apache.avalon.framework.service.Serviceable;
+import org.apache.avalon.phoenix.components.util.ResourceUtil;
import org.apache.avalon.phoenix.interfaces.ApplicationContext;
import org.apache.avalon.phoenix.interfaces.ConfigurationRepository;
import org.apache.avalon.phoenix.interfaces.ConfigurationValidator;
@@ -63,6 +68,7 @@
private SystemManager m_blockManager;
private final SarMetaData m_metaData;
+ private final File m_workDirectory;
/**
* The kernel associate with context
@@ -70,12 +76,31 @@
private Kernel m_kernel;
protected DefaultApplicationContext( final SarMetaData metaData,
+ final File workDirectory,
final ClassLoader classLoader,
final Logger hierarchy )
{
+ if( null == metaData )
+ {
+ throw new NullPointerException( "metaData" );
+ }
+ if( null == classLoader )
+ {
+ throw new NullPointerException( "classLoader" );
+ }
+ if( null == hierarchy )
+ {
+ throw new NullPointerException( "hierarchy" );
+ }
+ if( null == workDirectory )
+ {
+ throw new NullPointerException( "workDirectory" );
+ }
+
m_metaData = metaData;
m_classLoader = classLoader;
m_hierarchy = hierarchy;
+ m_workDirectory = workDirectory;
final DefaultThreadContextPolicy policy = new DefaultThreadContextPolicy();
final HashMap map = new HashMap( 1 );
@@ -99,6 +124,30 @@
throws Exception
{
m_blockManager = getManagementContext();
+ }
+
+ public InputStream getResourceAsStream( final String name )
+ {
+ final File file =
+ ResourceUtil.getFileForResource( name,
+ m_metaData.getHomeDirectory(),
+ m_workDirectory );
+ if( !file.exists() )
+ {
+ return null;
+ }
+ else
+ {
+ try
+ {
+ return new FileInputStream( file );
+ }
+ catch( FileNotFoundException e )
+ {
+ //Should never happen
+ return null;
+ }
+ }
}
public SarMetaData getMetaData()
1.79 +4 -1 jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/components/kernel/DefaultKernel.java
Index: DefaultKernel.java
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/components/kernel/DefaultKernel.java,v
retrieving revision 1.78
retrieving revision 1.79
diff -u -r1.78 -r1.79
--- DefaultKernel.java 31 Aug 2002 06:34:00 -0000 1.78
+++ DefaultKernel.java 6 Sep 2002 09:42:35 -0000 1.79
@@ -8,6 +8,7 @@
package org.apache.avalon.phoenix.components.kernel;
import java.util.HashMap;
+import java.io.File;
import org.apache.avalon.excalibur.i18n.ResourceManager;
import org.apache.avalon.excalibur.i18n.Resources;
import org.apache.avalon.framework.CascadingException;
@@ -237,6 +238,7 @@
}
public void addApplication( final SarMetaData metaData,
+ final File workDirectory,
final ClassLoader classLoader,
final Logger logger,
final Configuration server )
@@ -244,7 +246,7 @@
{
final String name = metaData.getName();
final SarEntry entry =
- new SarEntry( metaData, classLoader, logger, server );
+ new SarEntry( metaData, workDirectory, classLoader, logger, server );
m_entries.put( name, entry );
try
@@ -267,6 +269,7 @@
final DefaultApplicationContext context =
new DefaultApplicationContext( metaData,
+ entry.getWorkDirectory(),
entry.getClassLoader(),
entry.getLogger() );
1.12 +27 -4 jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/components/kernel/SarEntry.java
Index: SarEntry.java
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/components/kernel/SarEntry.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- SarEntry.java 6 Aug 2002 11:57:40 -0000 1.11
+++ SarEntry.java 6 Sep 2002 09:42:35 -0000 1.12
@@ -11,6 +11,7 @@
import org.apache.avalon.framework.logger.Logger;
import org.apache.avalon.phoenix.interfaces.Application;
import org.apache.avalon.phoenix.metadata.SarMetaData;
+import java.io.File;
/**
* This is the structure describing each server application before it is loaded.
@@ -20,24 +21,46 @@
final class SarEntry
{
private SarMetaData m_metaData;
-
private Configuration m_configuration;
-
private ClassLoader m_classLoader;
-
private Application m_application;
-
private Logger m_logger;
+ private File m_workDirectory;
+
protected SarEntry( final SarMetaData metaData,
+ final File workDirectory,
final ClassLoader classLoader,
final Logger logger,
final Configuration configuration )
{
+ if( null == metaData )
+ {
+ throw new NullPointerException( "metaData" );
+ }
+ if( null == classLoader )
+ {
+ throw new NullPointerException( "classLoader" );
+ }
+ if( null == logger )
+ {
+ throw new NullPointerException( "logger" );
+ }
+ if( null == workDirectory )
+ {
+ throw new NullPointerException( "workDirectory" );
+ }
+
m_metaData = metaData;
m_classLoader = classLoader;
m_logger = logger;
m_configuration = configuration;
+ m_workDirectory = workDirectory;
+ }
+
+ public File getWorkDirectory()
+ {
+ return m_workDirectory;
}
public Application getApplication()
1.1 jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/components/util/ResourceUtil.java
Index: ResourceUtil.java
===================================================================
/*
* Copyright (C) The Apache Software Foundation. All rights reserved.
*
* This software is published under the terms of the Apache Software License
* version 1.1, a copy of which has been included with this distribution in
* the LICENSE.txt file.
*/
package org.apache.avalon.phoenix.components.util;
import org.apache.avalon.framework.configuration.ConfigurationException;
import java.io.File;
import java.net.MalformedURLException;
/**
* A utility class for working with resources in default sar layout.
*
* @author <a href="mailto:peter at apache.org">Peter Donald</a>
* @version $Revision: 1.1 $ $Date: 2002/09/06 09:42:35 $
*/
public class ResourceUtil
{
private static final String SAR_PROTOCOL = "sar:";
private static final String SAR_INF = "SAR-INF/";
private static final String CLASSES = SAR_INF + "classes";
private static final String LIB = SAR_INF + "lib";
/**
* Expand any URLs with sar: protocol so that
* they accurately match the actual location
*
* @param codeBase the input url
* @return the result url, modified to file url if it
* is protocol "sar:"
* @throws ConfigurationException if invalidly specified URL
*/
public static String expandSarURL( final String codeBase,
final File baseDirectory,
final File workDirectory )
throws ConfigurationException
{
if( codeBase.startsWith( SAR_PROTOCOL ) )
{
final File file =
getFileForResource( codeBase.substring( 4 ),
baseDirectory,
workDirectory );
try
{
return file.toURL().toString();
}
catch( MalformedURLException e )
{
throw new ConfigurationException( e.getMessage(), e );
}
}
else
{
return codeBase;
}
}
public static File getFileForResource( final String location,
final File baseDirectory,
final File workDirectory )
{
String filename =
location.replace( '/', File.separatorChar );
if( filename.startsWith( "/" ) )
{
filename = filename.substring( 1 );
}
final File baseDir =
getBaseDirectoryFor( location, baseDirectory, workDirectory );
return new File( baseDir, filename );
}
private static File getBaseDirectoryFor( final String location,
final File baseDirectory,
final File workDirectory )
{
if( location.startsWith( CLASSES ) ||
location.startsWith( LIB ) )
{
return workDirectory;
}
else
{
return baseDirectory;
}
}
}
1.17 +9 -0 jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces/ApplicationContext.java
Index: ApplicationContext.java
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces/ApplicationContext.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- ApplicationContext.java 31 Aug 2002 06:34:00 -0000 1.16
+++ ApplicationContext.java 6 Sep 2002 09:42:35 -0000 1.17
@@ -12,6 +12,7 @@
import org.apache.avalon.framework.logger.Logger;
import org.apache.avalon.phoenix.metadata.SarMetaData;
import org.apache.excalibur.threadcontext.ThreadContext;
+import java.io.InputStream;
/**
* Manage the "context" in which Applications operate.
@@ -58,6 +59,14 @@
* @return the ClassLoader
*/
ClassLoader getClassLoader();
+
+ /**
+ * Retrieve a resource from the SAR file. The specified
+ * name is relative the root of the archive. So you could
+ * use it to retrieve a html page from within sar by loading
+ * the resource named "data/main.html" or similar.
+ */
+ InputStream getResourceAsStream( String name );
/**
* Get the Configuration for specified component.
1.14 +2 -0 jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces/Kernel.java
Index: Kernel.java
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces/Kernel.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- Kernel.java 7 Aug 2002 02:57:15 -0000 1.13
+++ Kernel.java 6 Sep 2002 09:42:35 -0000 1.14
@@ -10,6 +10,7 @@
import org.apache.avalon.framework.configuration.Configuration;
import org.apache.avalon.framework.logger.Logger;
import org.apache.avalon.phoenix.metadata.SarMetaData;
+import java.io.File;
/**
* @author <a href="mailto:peter at apache.org">Peter Donald</a>
@@ -22,6 +23,7 @@
* Adds an application to the container
*/
void addApplication( SarMetaData metaData,
+ File workDirectory,
ClassLoader classLoader,
Logger hierarchy,
Configuration server )
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> donaldp@apache.org wrote:
>
>> donaldp 2002/09/06 02:42:35
>>
> ...
>
>> Log:
>> Implement BlockContext.getResourceAsStream() so that a block is
>> capable of
>> locating resources in the sar file. This method will retrieve the
>> resource
>> regardless of where it is located.
>> This allows blocks to aquire resources regardless of where they
>> are located;
>> * in base directory
>> * in work directory
>> * in .sar file (in future)
>> * in some vfs (in future)
>
>
> This is a non-standard implementation of a Context...
>
> -1 *if* Blocks must aquire it using a cast, because it makes them
> unnecessarily dependent on Phoenix. Unnecessarily since this is a general
> concept.
>
> This can be done also as a Service, so it gets inserted as a
> dependency; if it must stay in the Context, it should be gotten from
> the context via a key that is declared in xinfo (I propose it to be
> standard).
>
Absolutely correct - there is not valid reason to extend context.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
>
>>
>>
>> Nicola Ken Barozzi wrote:
>>
>>>
>>> Nicola Ken Barozzi wrote:
>>>
>>>>
>>>> donaldp@apache.org wrote:
>>>>
>>>>> donaldp 2002/09/06 02:42:35
>>>>>
>>>> ...
>>>>
>>>>> Log:
>>>>> Implement BlockContext.getResourceAsStream() so that a block is
>>>>> capable of
>>>>> locating resources in the sar file. This method will retrieve
>>>>> the resource
>>>>> regardless of where it is located.
>>>>> This allows blocks to aquire resources regardless of where
>>>>> they are located;
>>>>> * in base directory
>>>>> * in work directory
>>>>> * in .sar file (in future)
>>>>> * in some vfs (in future)
>>>>
>>>>
>>>>
>>>> This is a non-standard implementation of a Context...
>>>>
>>>> -1 *if* Blocks must aquire it using a cast, because it makes them
>>>> unnecessarily dependent on Phoenix. Unnecessarily since this is a
>>>> general
>>>> concept.
>>>>
>>>> This can be done also as a Service, so it gets inserted as a
>>>> dependency; if it must stay in the Context, it should be gotten
>>>> from the context via a key that is declared in xinfo (I propose it
>>>> to be standard).
>>>
>>>
>>> I really didn't mean to veto formally, just regard this as an
>>> opinion on how it could also be done...
>>>
>>
>> In which case I'll veto this formally.
>>
>> -1 to the addition of BlockContext.getResourceAsStream()
>
>
> Stephen, I have been thinking about this today, and I looked at mail
> archives and at other widely used Contexts (ServletContext), and came
> to the conclusion that it's not an issue.
>
> What we both think is bad, it to have to cast a Context to a specific
> Context instance, which sounds as bad as casting a ServiceManager to a
> specific ServiceManager.
>
> Why?
> Because it's not declared in the descriptor.
Yep.
>
> Solution: declare it! ;-)
Exactly.
>
>
> Simply declare it, and the problem will vanish, since having
> dependencies to a Context or to the objecs in the Context is
> equivalent, there is just a further deferencing level, but the
> dependency is still there, you cannot remove it.
>
> Also, think of how other context are, they are like the BlockContext,
> and this is how users want it.
>
> For example, i was quite confused by the deferencing that the Cocoon
> Context does; to use the objectmodel methods I have to get the
> Context, then get the objectmodel from it, and then call some method!
>
> Honestly I now think that it's better for some cases that the users to
> have the context be declared as a dependency itself.
>
I completely agree.
Context is no less a dependency condition that a service dependency -
they are handled differently (a service depedency reference a component
that may have dependencies, etc. whereas a context depedency is a
dependecy on an java.lang.Object or derived type). This issue here is
"declaration" which I think is comming sometime soon. Based on the
updates on the CVS to seperate a release Phoenix from ongoping
development I'm happy to withdraw my -1s because I'm confident that we
will see declaration of context criteria inside Phoenix in the near
future. Assuming extensions are put in place such that they respect the
underlying context rules (i.e. access to an typed object via a key -
then we will not have a problem or at least reduce the scope of the
problem to identifed non-portable component types).
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
>
> Nicola Ken Barozzi wrote:
>
>>
>> Nicola Ken Barozzi wrote:
>>
>>>
>>> donaldp@apache.org wrote:
>>>
>>>> donaldp 2002/09/06 02:42:35
>>>>
>>> ...
>>>
>>>> Log:
>>>> Implement BlockContext.getResourceAsStream() so that a block is
>>>> capable of
>>>> locating resources in the sar file. This method will retrieve the
>>>> resource
>>>> regardless of where it is located.
>>>> This allows blocks to aquire resources regardless of where they
>>>> are located;
>>>> * in base directory
>>>> * in work directory
>>>> * in .sar file (in future)
>>>> * in some vfs (in future)
>>>
>>>
>>> This is a non-standard implementation of a Context...
>>>
>>> -1 *if* Blocks must aquire it using a cast, because it makes them
>>> unnecessarily dependent on Phoenix. Unnecessarily since this is a
>>> general
>>> concept.
>>>
>>> This can be done also as a Service, so it gets inserted as a
>>> dependency; if it must stay in the Context, it should be gotten from
>>> the context via a key that is declared in xinfo (I propose it to be
>>> standard).
>>
>> I really didn't mean to veto formally, just regard this as an opinion
>> on how it could also be done...
>>
>
> In which case I'll veto this formally.
>
> -1 to the addition of BlockContext.getResourceAsStream()
Stephen, I have been thinking about this today, and I looked at mail
archives and at other widely used Contexts (ServletContext), and came to
the conclusion that it's not an issue.
What we both think is bad, it to have to cast a Context to a specific
Context instance, which sounds as bad as casting a ServiceManager to a
specific ServiceManager.
Why?
Because it's not declared in the descriptor.
Solution: declare it! ;-)
Simply declare it, and the problem will vanish, since having
dependencies to a Context or to the objecs in the Context is equivalent,
there is just a further deferencing level, but the dependency is still
there, you cannot remove it.
Also, think of how other context are, they are like the BlockContext,
and this is how users want it.
For example, i was quite confused by the deferencing that the Cocoon
Context does; to use the objectmodel methods I have to get the Context,
then get the objectmodel from it, and then call some method!
Honestly I now think that it's better for some cases that the users to
have the context be declared as a dependency itself.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> - Now it seems to me that BlockContext would be an excellent candidate
> for the containerkit Context.
> I would humbly propose to maybe put the BlockContext in containerkit,
> deprecate the one in Phoenix, make the Phoenix one extend the
> containerkit one for compatibility, and make Cornestone blocks, which
> IIUC Peter also would like to see a components in excalibur (or
> something like that), use the containerkit context.
>
> What do you think, is it viable?
We have Context interface and that is completely workable. With the
two meta-info models that exist (excalibur/meta and excalibur/info) you
the ability to declare that a component has a requirement for the supply
of a context object such that it can be narrowed to some other
interface. However, you alway have the constraint that we are talking
about a Context derivative. Context works well if you respect its
purpose and function. Introducing something like BlockContext into
either the meta or info packages does not make sence because that are
about describing something like a BlockContext. Introducing
BlockContext into excalibur/container would make sence if there is
agreement across at least a couple of container projects. Introducing
BlockContext into containerkit is equivalent to leaving it where it is
Phoenix.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Stephen McConnell <mc...@apache.org>.
Paul Hammant wrote:
> Nicola,
>
>>>> There is now 2 -1s on BlockContext.
>>>
>>>
>>>
>>>
>>> I like BlockContext. +1
>>>
>>> ( By my reckoning you are now at only -1 )
>>
>>
>>
>> Naa, he withdrew them.
>
>
> Yup bloody partially threaded mail (poor substiture for NNTP).
>
>> Paul, it's not about what I like or what you like or what John Doe
>> likes.
>> BlockContext is a dependency to Phoenix, and *if* we want to make
>> cross-container compatible components, it's not a solution.
>
>
> BlockContext is a dependancy to Phoenix's hosted compoent API
> (phoenix-client.jar). You do not need the rest of Phoenix to mount
> blocks. It is easy to be compatible,
>
>> It binds you to Phoenix, but I assume that it's not a problem for
>> you, you also made a GUI in Phoenix, so I understand you don't see
>> the point.
>
>
> It does not bind you to phoenix per se. It binds you to the small
> redistrubitable phoenix-client.jar and the classes it contains. This
> is true interface/impl separated API, and not a 'blessed' API like
> Sun's Servlet or JMX (and other I presume).
True.
And today with Phoenix as is - it defines a variant of a the Avalon
Component Model. That's ok providing the users of the API understand
the implications of coding against a container specific API. Those
implications are generally bad and should be documeted as
"not-best-practice".
>
>> But Avalon is not only Phoenix, and as Peter pointed out he would
>> like to be able to use Cocoon components.
>> I would like to use Phoenix components.
>
>
> There is no reason that a container could not afford a contextualize()
> that supports castability to BlockContext, CocoonContext, FooContext
> and BarContext.
Only if (a) you have a meta-info model in place that declares the
context derivative, and (b) the derivatibve implementation documents its
contract relative to the pure Context interface. Without those two
things in-place there is one good reason - your component will not run
outside of the Phoinix environment.
>
>> If I make the Cocoon components dependent on CocoonContext, it would
>> not make reuse by Phoenix possible.
>
>
> Maybe an kernel extended Phoenix could support CocoonContext and
> BlockContext (see above).
I think that is the wrong way to look at the problem. User's should not
be consered with "workarounds" - that should be able to build and deploy
components without concern for the containerment environment. In the
rare cases where something additional is needed, a good container will
provide plug-in mechanisms that provide a means for extension of the
container. In the long term its possible for such containement
extensions to become standard - but only with the emergence of several
different contains and a vested interest by respective champions to
achieve a common platform. Out there in the real world there are clear
economic reasons for doing that - in the open-source world things are a
lot more gray.
>
>> Think about this, instead of just saying "I like it".
>
>
> You unfairly trivialize my posting.
>
>> Let me be more clear if I can: Phoenix has a specific Context that it
>> only can use. It's needed, regardless to how itthere; it's needed,
>> and from a functionality POV I like it too.
>
>
> You make your case well. You are wrong that it is the only container
> than can use the years old BlockContext. I have outlined a number of
> times ways that aloternate containers can be compatible with
> BlockContext. The committer have taken a vote on the recommendation
> that phoenix-client.jar be considered the way that these alternate
> containers be compatible with BlockContext. I really don't see where
> the problem is.
Phonieix today does not provide any support for context declaration
which means Phoenix depedency components are locked into (a) using the
client jar file AND providing an alternative implemetation of
BlockContext. Paul - that's a big "AND" that I think you may have
forgotten about. Every addition to the BlockContext interface is
another problem to be dealt with. The practicle solution is for other
container to fall-back to common denominator position - the Avalon
Framework - Context interface. This at least places the responsibility
onto component authors to be careful about containment depedencies.
>
>
>> So the thing should be dealt with on two levels, which we are doing:
>>
>> 1) define common attributes and possibly common Context keys to
>> access common functionality
>>
>> - thus we need to have a simpèle way of telling in the descriptor
>> what Context is needed.
>
>
> Personally I am only willing to get embroiled in an attributes
> discussion if you will cede to and honor a simple often repeated point
>
> Other containers *can* be compatible with BlockContext, it is not
> tied to the Phoenix impl, it is reimplementable.
Sure - and I could join the Republican Party - but is it a good idea?.
;-)
>
>> 2) provide a "standard" implementation for "standard" containers of
>> concrete implementations of the framework, which is Containerkit.
>>
>> - Now it seems to me that BlockContext would be an excellent
>> candidate for the containerkit Context.
>> I would humbly propose to maybe put the BlockContext in containerkit,
>> deprecate the one in Phoenix, make the Phoenix one extend the
>> containerkit one for compatibility, and make Cornestone blocks, which
>> IIUC Peter also would like to see a components in excalibur (or
>> something like that), use the containerkit context.
>
>
> This is perfectly possible.
Anything is possible.
> It would work as a strategy,
A strategy towards what objective ?
With the seperation of the meta-info content from containerkit -
containerkit is just another container API that will probably end up
inside Phoenix.
> It might please people who don't want any phoenix package imports in
> their components. However, there is no proven need for it given the
> fact that phoenix-client.jar is usable by alternative containers.
Providing every other container provides the implemetations for Phonix
specific stuff - can someone explain to me why this is good thing?
Steve.
>
> - Paul
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> Nicola,
>
>>>> There is now 2 -1s on BlockContext.
>>>
>>>
>>> I like BlockContext. +1
>>>
>>> ( By my reckoning you are now at only -1 )
>>
>> Naa, he withdrew them.
>
>
> Yup bloody partially threaded mail (poor substiture for NNTP).
>
>> Paul, it's not about what I like or what you like or what John Doe likes.
>> BlockContext is a dependency to Phoenix, and *if* we want to make
>> cross-container compatible components, it's not a solution.
>
> BlockContext is a dependancy to Phoenix's hosted compoent API
> (phoenix-client.jar). You do not need the rest of Phoenix to mount
> blocks. It is easy to be compatible,
Many are deprecated, and Peter has clearly said he is moving to an
improved component model... which I think is even better BTW :-)
>> It binds you to Phoenix, but I assume that it's not a problem for you,
>> you also made a GUI in Phoenix, so I understand you don't see the point.
>
> It does not bind you to phoenix per se. It binds you to the small
> redistrubitable phoenix-client.jar and the classes it contains. This is
> true interface/impl separated API, and not a 'blessed' API like Sun's
> Servlet or JMX (and other I presume).
Hmmm...
>> But Avalon is not only Phoenix, and as Peter pointed out he would like
>> to be able to use Cocoon components.
>> I would like to use Phoenix components.
>
> There is no reason that a container could not afford a contextualize()
> that supports castability to BlockContext, CocoonContext, FooContext and
> BarContext.
All in one? :-?
>> If I make the Cocoon components dependent on CocoonContext, it would
>> not make reuse by Phoenix possible.
>
> Maybe an kernel extended Phoenix could support CocoonContext and
> BlockContext (see above).
You mean that in contextualize(), the context I get will be castable to
any of the above or that the container gives the appropriate context to
the appropriate component?
Ok, probably the case is the latter.
From containerkit:
<context type="MyContextInterface">
<entry key="base" type="java.io.File"/>
<entry key="mode" type="java.lang.Object" optional="TRUE"/>
</context>
I'm cool with it :-)
>> Let me be more clear if I can: Phoenix has a specific Context that it
>> only can use. It's needed, regardless to how itthere; it's needed, and
>> from a functionality POV I like it too.
>
> You make your case well. You are wrong that it is the only container
> than can use the years old BlockContext. I have outlined a number of
> times ways that aloternate containers can be compatible with
> BlockContext. The committer have taken a vote on the recommendation
> that phoenix-client.jar be considered the way that these alternate
> containers be compatible with BlockContext. I really don't see where
> the problem is.
It's not a problem.
But since many things from there have somewhat landed in containerkit, I
was asking myself if it could go in excalibur as a common block; Phoenix
might have his own context that extends it still, but maybe it's time we
push it to a "standard" that is not only de-facto.
>> So the thing should be dealt with on two levels, which we are doing:
>>
>> 1) define common attributes and possibly common Context keys to access
>> common functionality
>>
>> - thus we need to have a simpèle way of telling in the descriptor what
>> Context is needed.
>
>
> Personally I am only willing to get embroiled in an attributes
> discussion if you will cede to and honor a simple often repeated point
Naaa, we can discuss on this too without fear, also since containerkit
already has the notion of a context desctiption.
> Other containers *can* be compatible with BlockContext, it is not tied
> to the Phoenix impl, it is reimplementable.
Ok, yes, ja, oui, it's true.
BlockContext is part of a Phoenix API, and is reimplementable and usable
outside of the Phoenix implementation.
>> 2) provide a "standard" implementation for "standard" containers of
>> concrete implementations of the framework, which is Containerkit.
>>
>> - Now it seems to me that BlockContext would be an excellent candidate
>> for the containerkit Context.
>> I would humbly propose to maybe put the BlockContext in containerkit,
>> deprecate the one in Phoenix, make the Phoenix one extend the
>> containerkit one for compatibility, and make Cornestone blocks, which
>> IIUC Peter also would like to see a components in excalibur (or
>> something like that), use the containerkit context.
>
>
> This is perfectly possible. It would work as a strategy, It might
> please people who don't want any phoenix package imports in their
> components. However, there is no proven need for it given the fact that
> phoenix-client.jar is usable by alternative containers.
Paul, it's not about not wanting Phoenix imports.
It's about opportunity.
The opportunity to officially push defacto standards that are useful to
a real Avalon standard.
If I want to use httpclient, I use httpclient. In your line of
reasoning, I should have used slide-client.
There is a reason why it was put in commons, and the same reason applies
to phoenix-client, well much of it.
Peter has made his view on the "common" stuff quite clear, and
containerkit is the right direction.
Think about this in that perspective.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Paul Hammant <Pa...@yahoo.com>.
Nicola,
>>> There is now 2 -1s on BlockContext.
>>
>>
>>
>> I like BlockContext. +1
>>
>> ( By my reckoning you are now at only -1 )
>
>
> Naa, he withdrew them.
Yup bloody partially threaded mail (poor substiture for NNTP).
> Paul, it's not about what I like or what you like or what John Doe likes.
> BlockContext is a dependency to Phoenix, and *if* we want to make
> cross-container compatible components, it's not a solution.
BlockContext is a dependancy to Phoenix's hosted compoent API
(phoenix-client.jar). You do not need the rest of Phoenix to mount
blocks. It is easy to be compatible,
> It binds you to Phoenix, but I assume that it's not a problem for you,
> you also made a GUI in Phoenix, so I understand you don't see the point.
It does not bind you to phoenix per se. It binds you to the small
redistrubitable phoenix-client.jar and the classes it contains. This is
true interface/impl separated API, and not a 'blessed' API like Sun's
Servlet or JMX (and other I presume).
> But Avalon is not only Phoenix, and as Peter pointed out he would like
> to be able to use Cocoon components.
> I would like to use Phoenix components.
There is no reason that a container could not afford a contextualize()
that supports castability to BlockContext, CocoonContext, FooContext and
BarContext.
> If I make the Cocoon components dependent on CocoonContext, it would
> not make reuse by Phoenix possible.
Maybe an kernel extended Phoenix could support CocoonContext and
BlockContext (see above).
> Think about this, instead of just saying "I like it".
You unfairly trivialize my posting.
> Let me be more clear if I can: Phoenix has a specific Context that it
> only can use. It's needed, regardless to how itthere; it's needed, and
> from a functionality POV I like it too.
You make your case well. You are wrong that it is the only container
than can use the years old BlockContext. I have outlined a number of
times ways that aloternate containers can be compatible with
BlockContext. The committer have taken a vote on the recommendation
that phoenix-client.jar be considered the way that these alternate
containers be compatible with BlockContext. I really don't see where
the problem is.
> So the thing should be dealt with on two levels, which we are doing:
>
> 1) define common attributes and possibly common Context keys to access
> common functionality
>
> - thus we need to have a simpèle way of telling in the descriptor what
> Context is needed.
Personally I am only willing to get embroiled in an attributes
discussion if you will cede to and honor a simple often repeated point
Other containers *can* be compatible with BlockContext, it is not tied
to the Phoenix impl, it is reimplementable.
> 2) provide a "standard" implementation for "standard" containers of
> concrete implementations of the framework, which is Containerkit.
>
> - Now it seems to me that BlockContext would be an excellent candidate
> for the containerkit Context.
> I would humbly propose to maybe put the BlockContext in containerkit,
> deprecate the one in Phoenix, make the Phoenix one extend the
> containerkit one for compatibility, and make Cornestone blocks, which
> IIUC Peter also would like to see a components in excalibur (or
> something like that), use the containerkit context.
This is perfectly possible. It would work as a strategy, It might
please people who don't want any phoenix package imports in their
components.
However, there is no proven need for it given the fact that
phoenix-client.jar is usable by alternative containers.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Paul Hammant wrote:
> Stephen,
>
>> There is now 2 -1s on BlockContext.
>
>
> I like BlockContext.
> +1
>
> ( By my reckoning you are now at only -1 )
Naa, he withdrew them.
Paul, it's not about what I like or what you like or what John Doe likes.
BlockContext is a dependency to Phoenix, and *if* we want to make
cross-container compatible components, it's not a solution.
It binds you to Phoenix, but I assume that it's not a problem for you,
you also made a GUI in Phoenix, so I understand you don't see the point.
But Avalon is not only Phoenix, and as Peter pointed out he would like
to be able to use Cocoon components.
I would like to use Phoenix components.
If I make the Cocoon components dependent on CocoonContext, it would not
make reuse by Phoenix possible.
Think about this, instead of just saying "I like it".
Let me be more clear if I can: Phoenix has a specific Context that it
only can use. It's needed, regardless to how itthere; it's needed, and
from a functionality POV I like it too.
But we also like to see components be able to work accross containers,
so the dependency has to be quite strong IMHO, or else it means that the
functionality it provides is general enough for quite all containers.
Now, given that most containers have some need from this stuff, Peter
rightly went on with containerkit, so that similar containers can share
the same underlying system.
And introduced attributes which are a terrific way to specify additional
stuff.
So the thing should be dealt with on two levels, which we are doing:
1) define common attributes and possibly common Context keys to access
common functionality
- thus we need to have a simpèle way of telling in the descriptor what
Context is needed.
2) provide a "standard" implementation for "standard" containers of
concrete implementations of the framework, which is Containerkit.
- Now it seems to me that BlockContext would be an excellent candidate
for the containerkit Context.
I would humbly propose to maybe put the BlockContext in containerkit,
deprecate the one in Phoenix, make the Phoenix one extend the
containerkit one for compatibility, and make Cornestone blocks, which
IIUC Peter also would like to see a components in excalibur (or
something like that), use the containerkit context.
What do you think, is it viable?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Paul Hammant <Pa...@yahoo.com>.
Stephen,
> There is now 2 -1s on BlockContext.
I like BlockContext.
+1
( By my reckoning you are now at only -1 )
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>
>
> Nicola Ken Barozzi wrote:
>
>>
>> Nicola Ken Barozzi wrote:
>>
>>>
>>> donaldp@apache.org wrote:
>>>
>>>> donaldp 2002/09/06 02:42:35
>>>>
>>> ...
>>>
>>>> Log:
>>>> Implement BlockContext.getResourceAsStream() so that a block is
>>>> capable of
>>>> locating resources in the sar file. This method will retrieve the
>>>> resource
>>>> regardless of where it is located.
>>>> This allows blocks to aquire resources regardless of where they
>>>> are located;
>>>> * in base directory
>>>> * in work directory
>>>> * in .sar file (in future)
>>>> * in some vfs (in future)
>>>
>>>
>>>
>>>
>>> This is a non-standard implementation of a Context...
>>>
>>> -1 *if* Blocks must aquire it using a cast, because it makes them
>>> unnecessarily dependent on Phoenix. Unnecessarily since this is a
>>> general
>>> concept.
>>>
>>> This can be done also as a Service, so it gets inserted as a
>>> dependency; if it must stay in the Context, it should be gotten from
>>> the context via a key that is declared in xinfo (I propose it to be
>>> standard).
>>
>>
>>
>> I really didn't mean to veto formally, just regard this as an opinion
>> on how it could also be done...
>>
>
> In which case I'll veto this formally.
>
> -1 to the addition of BlockContext.getResourceAsStream()
>
> This is not 2 -1s on BlockContext (there is also the requestShutdown
> method addition that has not been rectified).
Correction:
There is now 2 -1s on BlockContext.
>
>
> Cheers, Steve.
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Nicola Ken Barozzi wrote:
>
>>
>> donaldp@apache.org wrote:
>>
>>> donaldp 2002/09/06 02:42:35
>>>
>> ...
>>
>>> Log:
>>> Implement BlockContext.getResourceAsStream() so that a block is
>>> capable of
>>> locating resources in the sar file. This method will retrieve the
>>> resource
>>> regardless of where it is located.
>>> This allows blocks to aquire resources regardless of where they
>>> are located;
>>> * in base directory
>>> * in work directory
>>> * in .sar file (in future)
>>> * in some vfs (in future)
>>
>>
>>
>> This is a non-standard implementation of a Context...
>>
>> -1 *if* Blocks must aquire it using a cast, because it makes them
>> unnecessarily dependent on Phoenix. Unnecessarily since this is a
>> general
>> concept.
>>
>> This can be done also as a Service, so it gets inserted as a
>> dependency; if it must stay in the Context, it should be gotten from
>> the context via a key that is declared in xinfo (I propose it to be
>> standard).
>
>
> I really didn't mean to veto formally, just regard this as an opinion
> on how it could also be done...
>
In which case I'll veto this formally.
-1 to the addition of BlockContext.getResourceAsStream()
This is not 2 -1s on BlockContext (there is also the requestShutdown
method addition that has not been rectified).
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
>
> donaldp@apache.org wrote:
>
>> donaldp 2002/09/06 02:42:35
>>
> ...
>
>> Log:
>> Implement BlockContext.getResourceAsStream() so that a block is
>> capable of
>> locating resources in the sar file. This method will retrieve the
>> resource
>> regardless of where it is located.
>> This allows blocks to aquire resources regardless of where they
>> are located;
>> * in base directory
>> * in work directory
>> * in .sar file (in future)
>> * in some vfs (in future)
>
>
> This is a non-standard implementation of a Context...
>
> -1 *if* Blocks must aquire it using a cast, because it makes them
> unnecessarily dependent on Phoenix. Unnecessarily since this is a general
> concept.
>
> This can be done also as a Service, so it gets inserted as a dependency;
> if it must stay in the Context, it should be gotten from the context via
> a key that is declared in xinfo (I propose it to be standard).
I really didn't mean to veto formally, just regard this as an opinion on
how it could also be done...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon-phoenix/src/java/org/apache/avalon/phoenix/interfaces
ApplicationContext.java Kernel.java
Posted by Nicola Ken Barozzi <ni...@apache.org>.
donaldp@apache.org wrote:
> donaldp 2002/09/06 02:42:35
>
...
> Log:
> Implement BlockContext.getResourceAsStream() so that a block is capable of
> locating resources in the sar file. This method will retrieve the resource
> regardless of where it is located.
>
> This allows blocks to aquire resources regardless of where they are located;
> * in base directory
> * in work directory
> * in .sar file (in future)
> * in some vfs (in future)
This is a non-standard implementation of a Context...
-1 *if* Blocks must aquire it using a cast, because it makes them
unnecessarily dependent on Phoenix. Unnecessarily since this is a general
concept.
This can be done also as a Service, so it gets inserted as a dependency;
if it must stay in the Context, it should be gotten from the context via
a key that is declared in xinfo (I propose it to be standard).
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>