Hi devs,
Since the JSR330 is now accepted as final and thus as a standard, I'd like to propose that we modify our component annotations to use it.
Rationale
========
The advantages of using it are:
* Be standard, ie:
** Our components will be able to be re-used by injectors other than ours (Guice for example)
** Since IDEs will support JSR330 they'll be able to offer features for our code (auto complete, graph, etc), for ex http://blogs.jetbrains.com/idea/tag/dependency-injection/
Proposed Changes
===============
Note: JSR330 doesn't specify how components should be bound, hence the need to keep xwiki-specific metadata for the bindings.
* @Component and @ComponentRole stay unchanged
* Deprecate @Requirement, replaced by @Inject
* Use @Named or application-specific annotations (based on @Qualifier) instead of hints specified in the @Requirement annotation
* Add new @Role(Class) to specify a dependency role in the case of collections (since generics are not available using reflection in Java)
* Deprecate @InstantiationStrategy, replaced by @Singleton. We don't need to introduce any other scope annotations for now.
* Note that the default scope in the JSR330 spec is "per lookup". Since our default is singleton, we'll need to add @Singleton annotations everywhere we used to not have anything.
Example before:
@Component("html")
public class HTMLMacro extends AbstractMacro<HTMLMacroParameters>
{
...
@Requirement
private HTMLCleaner htmlCleaner;
...
@Requirement("xhtmlmacro/1.0")
private PrintRendererFactory xhtmlRendererFactory;
...
Same example after the change:
@Component("html")
public class HTMLMacro extends AbstractMacro<HTMLMacroParameters>
{
...
@Inject
private HTMLCleaner htmlCleaner;
...
@Inject
@Named("xhtmlmacro/1.0")
private PrintRendererFactory xhtmlRendererFactory;
...
WDYT?
Thanks
-Vincent
Hi,
yesterday I'v set up a new wiki (with the new Milestone 2).
I've followed the instructions to set up short urls:
http://platform.xwiki.org/xwiki/bin/view/Main/ShortURLs
with one difference. Instead of using mod_redirect for the Apache HTTPD
I'm using mod_proxy and mod_rewrite so that an url
www.mydomain.com/docs -> (internal-ip) 192.168.1.n/appContext
The effect is that from the internet only the new naming schema is
visible and not the default 'long' url resolution.
This works fine so far, except for one issue:
In all cases where xwiki generates redirection urls like this example
for "Logout"
/docs/logout/XWiki/XWikiLogout?xredirect=http://www.mydomain.com/appContext/docs/XWik/aha
What's wrong IMHO is "appContext" - part of the ?xredirect - this
exposes the internal webapppath back to the caller.
I have configured the xwiki.cfg to not using the appPath:
xwiki.webapppath=/ but this setting is not used,
instead the deployment webappPath is used for ?xredirect.
In all other cases (except the ?xredirect) the configured webapppath
seems to be used correctly.
This is my configuration:
in xwiki.cfg:
xwiki.webapppath=/ (because this is handled by mod_rewrite)
xwiki.defaultservletpath=docs/ (use "docs" instead of "bin")
xwik.showviewaction=0
in web.xml
param-value of "redirectHomeServlet" to http://www.mydomain.com/docs/Main
and added a <servlet-mapping> pattern for "action" to /docs/*
for completeness here's the mod_rewrite <VirtualHost> configuration (Ubuntu)
<VirtualHost *>
ServerName www.mydomain.com
ServerAdmin wiki(a)mydomain.com
RewriteEngine On
RewriteLog /var/log/wiki_rewrite.log
RewriteLogLevel 2
CustomLog /var/log/wiki_custom.log common
ErrorLog /var/log/wiki_error.log
# use [P] for Proxy and NOT [R] for redirect !
RewriteRule ^/(.*) http://www.mydomain.com/appContext/$1
[L,P,E=proxy_ok:1]
ProxyPreserveHost On
</VirtualHost>
and this is the mod_proxy
<IfModule mod_proxy.c>
#turning ProxyRequests on and allowing proxying from all may allow
#spammers to use your proxy to send email.
ProxyRequests Off
<Proxy *>
AddDefaultCharset off
Order deny,allow
Deny from all
# Proxies just in case Proxy_ok is set
Allow from env=proxy_ok
</Proxy>
# Not sure whether we need this ...
# Enable/disable the handling of HTTP/1.1 "Via:" headers.
# ("Full" adds the server version; "Block" removes all outgoing
Via: headers)
# Set to one of: Off | On | Full | Block
ProxyVia On
</IfModule>
thanks for your support
Andreas
Hi devs,
We have a limitation in the xwiki/2.0 parser related to the way macros
are parsed: impossible to have the ending syntax of a macro as content
of this macro.
Here is the related jira issue: http://jira.xwiki.org/jira/browse/XWIKI-5077
A good example is: i want to have "{{/code}}" alone as the content of
a code macro. That's impossible.
The only way to have {{/code}} in the content is with:
{{code}}
{{code}}
{{/code}}
{{/code}}
or
{{code}}
~{{/code}}
{{/code}}
but in the first case you get "{{code}}" you did not want and in the
second you get "~" you did not want.
Only solution i can see is to specifically handle escaping of ending
macro syntax inside macros of the same name.
Here is some examples:
1)
{{code}}
~{{/code}}
{{/code}}
would give code macro containing "{{/code}}"
2)
{{code}}
~{{/somemacro}}
{{/code}}
would give code macro containing "~{{/somemacro}}"
3)
{{code}}
~~{{/code}}
{{/code}}
would give code macro containing "~" followed by the text "{{/code}}"
4)
{{code}}
~~~{{/code}}
{{/code}}
would give code macro containing "~{{/code}}"
5)
Then double escaping for each level to escape:
{{box}}
{{box}}
~~~{{/box}}
{{/box}}
{{/box}}
would give box macro containing a box macro containing the text
"{{/box}}": the first pass change "~~~{{/box}}" into "~{{/box}}" like
in example 4) and the second pass escape "{{/box}}" like in example
1).
So WDYT ?
Here is my +1
--
Thomas Mortagne
Currently everything is saved with the content author set to XWiki.Admin.
This means that in a default system, every single page has programming access and any bug which
allows for arbitrary velocity to be evaluated or even allows arbitrary xwiki syntax to be rendered
in that page will be a PR leak.
We can either (A) begin making pages with contentAuthor = XWiki.XWikiGuest
or (B) we could create a new default username which has no PR.
I'm +1 for A because of it's simplicity and adding default usernames seems ugly to me.
Caleb
Another though, should we change the values of "creator" and "author" at the same time?
The XWiki development team is pleased to announce the release of XWiki
Enterprise 2.3 Milestone 2.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This is second and last milestone of the XWiki Enterprise 2.3 version.
Main changes from 2.3 Milestone 1:
* New Annotations section in the Administration
* New spanish translations for the WYSIWYG editor
* Lots of bugs fixes
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise23M2
Thanks
-The XWiki dev team
In XWiki(Hibernate|Jcr)Store#saveXWikiDoc(), the attachement list is
persisted, but the attachement contents are not persisted.
A) I would like to take care of also persisting attachment contents when
these contents are loaded and marked dirty
(XWikiAttachmentContent#isContentDirty() == true).
Why I would like to change this ?
1) I see no use case that would have to persist reference to an attachment
and drop its content at the same time, which create records with a size
field set to n bytes, while the attachment is 0 or m bytes.
2) When for example an XWikiDocument#copy() is followed by an
XWiki#saveDocument() (on the newly created document), without also calling
XWikiDocument#saveAllAttachements(), the cache store contains the documents
with all their attachments contents, while the DB has not really persisted
these contents.
3) In XWikiHibernateAttachmentStore#saveAttachmentContent(), the default
is to persist the document, this is not consistent with the document not
doing the same in reverse. (I would have better understand that persisting
attachment contents does not persist the document.)
4) isContentDirty is properly maintained, and currently it is nearly
unused, making the false impression that attachments content are persisted
properly
5) This issue is invisible in normal XWiki usage, since we take care of
saving attachments contents to avoid it everywhere, for example
in XWiki#copyDocument(), attachments contents are saved "manually".
6) As a application developer, using the internal API in groovy, my
collegue has missed it, and we have loose production data, since during
testing, the cache has always hide the issue. I really dislike API that
could introduce inconsistencies in the DB and moreover when you loose large
amount of data.
B) This change has no real impact on any code that would take care of saving
the attachments separatly, it will just be saved twice, isContentDirty()
currently only prevent useless archiving. This could be optimized by not
saving contents as well when it is not dirty, but I do not want a negative
vote on the rest for just this. So please vote this as B)
C) I also would like to optimize existing internal usage, removing useless
call to saveAttachmentContent() in XWiki.copyDocument() for example. This
could have an impact on a custom store that does not take care of saving
attachments contents while saving documents. I doubt many user has such a
store and release notes could mention this incompatibility.
This is my +1 for A) B) and C)
Denis
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
Hi,
I'm implementing the mail entitled "[Proposal] Rationalize our projects and SVN structure" and I need to start creating extensions.xwiki.org (a **first** version of it).
Here's my current thinking re its structure:
* An ExtensionClass
- Description
- icon (optional)
- Download page (optional)
- created by
- contributor
- bundled with (none, top level projects except contrib, extensions)
- content (with template having Tested With + Requirements sections)
- type (macro, snippet, application, plugin, skin, other)
* A MacroClass
- macro type
* A SnippetClass
- languages (multi choice list: script languages)
Note: In the future we'll need to map these classes to the Extension Manager descriptor, with dependencies for example.
* Have an ExtensionClassSheet that does basically the same thing as now
* Have an ExtensionClassTemplate with predefined sections to guide the author: Usage, Installation & Requirements, Tested With (note: Installation & Requirements could also be put in the Download page, common to all versions)
* Keep the Download classes too for now
* On the home page, have a big livetable mapped to ExtensionClass for now.
* Put all extensions in an Extensions space
* Use a prefix of "Extension"
* When an extension is made of different "types", then bundle it as a zip with type "other". For example the Watch extension is made of a XAR + 2 jars, it would be bundled as a zip and a type of "other".
* Move Module References to platform.xwiki.org
* Possibly write some scripts to help migrate current content on code.xwiki.org to extensions.xwiki.org
WDYT?
Thanks
-Vincent